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NET"ét 
a rendszergazdáknak" 


Ahogy az operációs rendszerek egyre bonyolultabbá válnak, úgy veszítjük 
el azt a képességünket, hogy mindent átlássunk bennük. Kérdezhetik, vajon 
baj-e ez? Hisz a tévékészülékekbe beépített mütyürkék funkcióját sem is- 
merjük, mégis tudunk tévét nézni. Ez igaz. De tévét javítani nem. Az infor- 
matikustól pedig néha azt várják el, hogy operációs rendszert javítson, te- 
hát mégiscsak alaposan kell ismerni! 


Úgy gondolom, a legmélyebb ismeretek megszerzéséhez csakis a programozáson keresztül ve- 
Zet az út. Nem kell hatalmas alkalmazásokat fejleszteni, épp elég az operációs rendszer függ- 
vényeit hívogatni ahhoz, hogy más képet kapjunk a rendszerkomponensek működéséről. De 
hogyan fogjunk hozzá? 

Annak idején, a DOS-korszakban egyszerűbb volt a helyzet: az oprendszer mindössze néhány 
tucat fájlból állt, a rendszerszolgáltatásokat pedig egységesen (megszakításkéréssel) lehetett 
meghívni. Még a rendszer bővítése is egyszerű volt: írj egy SYS-t és kész! 

Nem mintha ez tényleg annyira egyszerű lett volna, de valahogy abban a bütykölős korszak- 
ban sokkal többen vájkáltak a rendszerek mélyén, mint ma. Sokan fejlesztettek egérmeghajtót, 
vírust, míg az egyik legelterjedtebb hobby a tárrezidens billenyűzet-átdefiniáló programok írá- 
sa volt. Magam is írtam egyet. Máig emlékszem, hogyan kell kilépni egy DOS-os programból. 
Egy különleges, soha vissza nem térő szoftvermegszakítás meghívásával: 


MOV AH, 4Ch 
INT 214 


De próbáljuk meg ma kibővíteni a rendszert! Windows DDK? Fuj! Service írása? Na neeee. 
Windows API-függvények meghívása? Ilyet még a guruk sem tesznek. Ezek után mi maradt a 
kocaprogramozóknak? Egy marék COM-komponens néhány populáris szolgáltatás elérésére: 
ADSI, ADO, CDO, FSO - és a kör bezárult. Talán még a CAPICOM létezik, bár ezt én magam 
sohasem használtam. Az ember ilyenkor hajlamos kisgyermekként tekinteni a világra: amit nem 
látok, az nincs is. Nincs Performance Monitor? Nincs Eventlog? Ezeknek nincs szerkezetük, lé- 
lektanuk, működésük? De van! 


A .NET-keretrendszer 


A Microsoft az egyre tobzódó igény hatására nekiállt a rendszereiben megbúvó lehetőségek 
megnyitásának, ha nem is COM-komponensek formájában, hanem a .NET-keretrendszer része- 
ként. És kiderült, hogy a szolgáltatásoknak mintegy 496-a volt idáig kényelmesen elérhető! Az 
eddigi négy (nagy jóindulattal öt) COM-objektum helyett mintegy hatezer (6000) objektumot 
kaptunk. Hogyan lehet hatezer bigyót értelmesen kezelni? Hierarchikus besorolásban, fában. 
Ha bármelyik informatikai területen elszaporodnak a bigyók, ott mindig ültetünk egy fát, arra 
aggatjuk a bigyókat s ezzel rakunk rendet. Lásd: könyvtárszerkezet, regisztrációs adatbázis, 
LDAP-címtár stb. 

A .NET-keretrendszerben a fa ágainak neve: névtér; az objektumokat úgynevezett névterekben 
találjuk. Aki a .NET-et ismeri, az ezt a faszerkezetet látja át valamennyire. Aki pedig még egy- 
két objektumot ki is próbál, meg is szólít, egy nagyságrenddel többet tud az operációs 
rendszerről, mint azok, akik erre nem veszik a fáradságot. Ez a tudáskülönbség éles helyzetek- 
ben mutatkozik meg igazán: könnyebb a hibaelhárítás, ha ismerjük a rendszer lelkét! 


.NET-et a rendszergazdáknak! 


A címben feltett kérdésre tehát igen a válasz. Igen, járjuk be a .NET-kertet! Mi kell egy ilyen kirán- 
duláshoz? Csupa régi ismerős: CMD.EXE és Notepad. A negyedik oldalon kezdődik a (tor)túra. 


Fóti Marcell 

marcellfGnetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


szám / 
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.IET-et a rendszergazdáknak! 
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roess degrtőe (1682), Mhrosd etei 


Avagy kiből (nem) lesz programozó? SS ásás 


Agg CAMEL tő debug the ápoleaban, 





Előrebocsátom: nem vagyok programozó. Egyszerűen csak nekem is volt gyerek- TI]. eve ] 
szobám, benne egy Enterprise 128 ,szuper"számítógéppel, amivel örökre magam- 
ba szívhattam a Basic nyelvet. Ezen a stabil alapon állva vetettem bele magam a .NET keretrendszer kiaknázásába. Eszköz- 
készletem a Notepad.EXE, programozási nyelvem a Ctt lesz. Vágjunk bele! 





Portál Paraldigmal — DU. 


Network Load Balancing Services: a nap 24 órájában 
elérhető portál szolgálatában 

Manapság naponta hallhatunk híreket új portálszolgáltatások születéséről, és régebbiek 
megszűnéséről. A sikeres portál hasznos információkkal látja el látogatóit, szolgáltatásait 
egyre többen és gyakrabban veszik igénybe. A legsikeresebbeket sok ember elsődleges hírforrásként használja, vagy szolgál- 
tatásainak használatával végzi mindennapi munkáját. Azonban még egy ilyen népszerű és nagy látogatottságú portáltól is 
könnyen elpártolhatnak a felhasználók, ha gondok merülnek fel a kiszolgálók elérhetőségében, ha a szolgáltatások akadoz- 
nak, vagy ha a rendszer kényelmetlenül lassúvá válik. És ismét jön a portál para. 








Funkcióalapú hozzáférésvezérlés 
Windows Server 2003 Authorization Manager 


A jogosultságállítás hagyományos módja az egyes erőforrásokon lévő joglisták 
megfelelő beállítása. Igen ám, de minél bonyolultabb egy alkalmazás, annál ne- 
hezebb, sőt egyenesen lehetetlen fájl- és egyéb alacsonyszintű jogokra bontani a 

hozzáférést. Elvontabb, magasabb szintű jogosultságkezelést tesz lehetővé a Win- 
dows 2003 Authorization Manager alrendszere. 








Active Directory Recovery 


zene en ElRmszintű AD-visszaállítás" 
fg. krezszzeétjj a Aelita ERDisk For Active Directory 


b Domain 





Controller Az Aelita Software ERDisk For Active Directory terméke egy olyan eszköz a rendszer- 
GR ÜKEKtÁGA I adminisztrátorok kezében, aminek használatával bátran állíthatjuk, hogy a címtár, 
connren SZ ] illetve az azt hordozó szerverek működése bombabiztos. Minden, ami az AD menté- 
Ke RB séhez és helyreállításához kell. 


A DRLP rejtett szépségei — II. 


A Windows-rendszerekben működő DHCP-kiszolgáló telepítése 
több, egymástól független lépésből áll. A hitelesítés buktatóinak 
ismertetése és az első címtartomány létrehozása után azt vizsgál- 
juk, milyen integrációt lehet megvalósítani a címkiosztó és a 
névfeloldó szolgáltatások között. 





byógyszeresdoboz 
III. rész — Windows 2000 Server 
Resource Kit 


Network 4- Management -- Tools. Nyilvánvaló, hogy az ide tartozó eszkö- 
zök fontosságát nem kell hosszú lére eresztve indokolni. Network minden- 
hol van, a Management a rendszergazda munkájának jelentősen kidombo- 
rodó része, úgyhogy nézzük sebesen a harmadik összetevőt. 


KEN ZTTT 





Vezeték nélküli LAIM technológiák 


és a Windows XP 














A vezeték nélküli LAN-ok és hálózati szolgáltatások kiterjesztik a hálózati ki 
felhasználó szabadságát, megoldanak több, a fizikai kábelezésű hálóza- an 
tokkal kapcsolatos problémát, és sok esetben még a hálózattelepítések tj 
költségeit is lecsökkentik. E szabadság mellett azonban a zsinór nélküli a 
LAN-ok új kihívásokat is támasztanak. és 

e. 

s 


na —7 Biztonságos aláíráskezelő alkalmazás II. 


Aláírási szabályzat 

Sorozatunk előző részében áttekintettük az aláíráskezelő alkalmazások- 
hoz kapcsolódó jogi környezetet, a tanúsítással kapcsolatos tudnivalókat, 
valamint az aláíráskezelés biztonságnak alapvető kérdéseit. Jelen rész az 
Tranzakciós környezet (1 elektronikus aláírással és annak feldolgozásával kapcsolatos fogalmakat, 


CC n ) (0) () jellemzőket kívánja megismertetni, különös tekintettel az aláírási sza- 
[1]  bályzatra. 


Kezelési útmutató Kezelési útmutató Kezelési útmutató 


1 


Követelményspecifikáció Konfigurációs leírás Követelményspecifikáció 








Alkalmazás ] Alkalmazás Alkalmazás 

















Exchange 2000 scripting 


Az ismeretlen eszköz 





































































































































































































A windows scripting használatával nem csak a unix adminok kiváltsága a feladatok egyszerű 
megoldása rövid segédprogramokkal. Az exchange is támogatja a scriptek használatát, amivel v / 
sok gondot le tud venni a vállunkról. Lássuk! ] 
MezourceT 7] 
TT 
111 Wser1:3] 
1 Adatbáziselérés modellezé 
27 
TE atbáziselérés modellezése 
271 a 4 ei s. veyszegzz ds 
BE aló 110 Gyakori probléma, hogy a tesztkörnyezetben remekül működő adatbázis- 
7707 20 [2 alkalmazások éles működés közben rengeteg galibát okoznak, a felhasz- 
EL júl, Tsz ET nálók összeakadnak, a terhelés növelésével a válaszidő drasztikusan meg- 
TIT ús kese nő. Ilyenkor óriási összegeket fordítunk a hiba felderítésére és kiküszöbö- 
171 né a. ze a ze a ő 
s álá 210 lésére. Ez azonban elkerülhető lenne egy kis előretekintéssel... 
170 ae E 
e. ja 171 
TIT 
an TIT 
Swaiting? 
IZHETTEZ 
att TS 
tinit::0 sent téssáll 
waiting. 
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:" Avagy kiből (nem] lesz programozó? / 


NET-et a rendszergazdáknak! 
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.ET-et a rendszergazdáknaki 


Avagy kiből (nem) lesz programozó? 


Előrebocsátotm: nem vagyok programozó. Egyszerűen csak nekem is volt gyerekszobám, benne egy 
Enterprise 128 ,szuper"számítógéppel, amivel örökre magamba szívhattam a Basic nyelvet. Ezen a sta- 
bil alapon állva vetettem bele magam a .NET keretrendszer kiaknázásába. Eszközkészletem a 
Notepad.EXE, programozási nyelvem a Ctt lesz. Vágjunk bele! 


Aki fejébe veszi, hogy felderíti a .NET-keretrendszer szolgálta- 
tásait, óhatatlanul programozni fog. Minden programok 
legegyszerűbbike a parancssori, vagy más néven konzolalkal- 
mazás. Minek ide grafikus felület, egérkezelés és egyéb bonyo- 
dalmak? Írjunk csak jól bevált parancssori eszközöket, ame- 
lyek tökéletesen alkalmasak arra, hogy mindent kipróbáljunk. 


Konzolprogramot írunk 


A konzolprogramok nagy előnye, hogy olyan környezetben is 
felhasználhatók, ahol nincs felhasználói felület. Ilyen például 
egy logon script, ami teljesen ,vakon" fut le, nincs nyomó- 
gombja, de még csak ablaka sem. A .NET-keretrendszerrel el- 
készített programocskák azt az ígéretet hordozzák magukban, 
hogy , tetszőleges" operációs rendszeren működni fognak. Per- 
sze ahol van .NET Framework. Manapság Win98-tól Windows 
2003-ig, a jövőben pedig mobiltelefontól Linuxig terjed a ská- 
la — csak győzzük kivárni! 

Minden .NET konzolprogramocska egy, az objektumorientált 
keretrendszer lelkivilágából fakadó sablonba írandó. Nem úgy 
van, mind például VBScript esetén, hogy az ember leír egy 
sort, pl: 


WriteLine("Jo napot"); 





...és kész! A .NET-es programoknak van egy bizonyos betartan- 
dó szerkezetük. Létre kell hozni egy osztályt (tetszőleges né- 
ven), és abba kell beleszőni a Main() fedőnevű főfüggvényt, 
aminek meghívásával a program futása elindul. Íme a sablon: 





class akarmi 

kezés void Main() 
üz jöhet a lényeg 
; 


Ennyi. Ha ezt lefordítjuk .EXE-vé, egy semmit sem csináló 
programhoz jutunk. De hogy ne maradjon megmagyarázatlan 
kulcsszó, említsük meg, mi mit jelent a mi számunkra (tehát tu- 
dománytalanul)! 

HA A class kucsszóval egy új osztályt definiálunk. Hogy 
miért? Mert a keretrendszer csak így fogadja be a prog- 
ramocskánkat. Ez egy szükséges rossz. 

TA A static jelentése a mi számunkra (itt és most): az adott 
metódust vagy függvényt (pl. Main()) meg lehet hívni az 
osztály ,példányosítása" nélkül is. Ennek inkább a hívó 
fél számára van jelentősége. (A hívó fél ez esetben a 
. NET futtató maga.) 


A void: ezzel adjuk meg, hogy a Main() függvény nem ad 
vissza semmilyen értéket 

A a Main() pedig minden C-alapú nyelven írt program be- 
lépési pontja. 


Alkalmazások fordítása 


Apropó fordítás: aki megszokta a VBScript interpretált futtatá- 
sát, annak talán furcsa érzés igazi, lefordított .EXE-ket készíte- 
ni, de nem nagy ördöngösség ez sem. Csak ismerni kell a for- 
dítóprogramot — mint ahogy Windows Scripting Host haszná- 
latánál a WSCRIPT-CSCRIPT párost illik ismerni... 

Itt jegyzem meg, hogy a lefordított .NET-es programok nem gé- 
pi kódot, hanem úgynevezett IL-kódot tartalmaznak, emiatt fut- 
tatás előtt még egy fordító végigfut rajtuk: a Just In Time Com- 
piler. De ezzel nekünk már nem kell törődnünk. 

A fordítást a CSC.EXE nevű kompiler végzi el, aki valahol a 
.NET-keretrendszer mélyén üldögél és sajnos nincs bent a 
PATH-ban, de könnyen betehető az alábbi utasítás segítségé- 
vel: 


set path-$path$6;C : WINDOWS Microsoft .NETN 
§  Frameworkiv1.1.4322 


(A könyvtárnév függ az éppen telepített . NET keretrenszer ver- 
ziószámától. A fenti példában a 1.1.4322-es verziójú keret- 
rendszert használjuk (1.1).) 

És most fordítsuk le az előbbi, üres programot, amit Note- 
paddel ügyesen belemásoltunk egy semmi.cs nevű textfájlba: 


CSC semmi.cs 


Ha nincs hiba, ezt kapjuk válaszul: 


Microsoft (R) Visual Cit .NET Compiler version 
7.10.3052.4 

for Microsoft (R) .NET Framework version 1.1.4322 
Copyright (C) Microsoft Corporation 2001-2002. All 
rights reserved. 


Elkészült a semmi.EXE (IL-kód!). Most futtassuk le! Mit csinál? 
Semmit! Miért olyan lassú? A Just In Time fordítás miatt. 


Tegyünk valamit! 

Az elkészült SEMMI.EXE funkcionalitásának bővítése legyen 
az, hogy programocskánk kiírja a képernyőre az alábbi örök- 
zöld mondatot: , Hello World!" 


Ehhez ismernünk kell a .NET konzolfirkáló lehetőségét, melyet 
logikus módon a Console osztály valósít meg. Kódunkat a 
Main() függvény törzsébe kéretik belepakolni! Ha csak ennyit 
írnánk: 


Console.WriteLine( "Hello World!"); 


...Sajnos le sem fordulna a kódunk, mert a .NET-objektumok 
egy hierarchikus névtérben tanyáznak, és nem adtuk meg a 
Console objektumhoz vezető utat. A helyes hivatkozás ez: 


System.Console.WriteLine("Hello World!"); 


...és már le is fordul! Sőt, fut is! 

Érdekesség: nem kellett objektumpéldányt "szülni" a Console 
osztályból, hanem direktben meghívhattuk a WriteLine metó- 
dusát. Ezt jelenti az, hogy a metódus statikus. No meg publi- 
kus. És ráadásul void is. Ilyennek írták meg Redmondban: 


public static void WriteLine(string value); 


Echo World! - paraméterek átvétele parancssorból 


Következő lépésben már adatokat veszünk át a parancssorból, 
és — az egyszerűség kedvéért — visszaírjuk azokat a képernyő- 
re. Tehát a cél egy olyan HELLO.EXE megalkotása, amit ha pa- 
rancssori paraméterekkel meghívunk, azokat kiírja (echózza) a 
képernyőre. Valahogy így: 


110 subidubi 
bi 


8 TI 


(vi ALT LELT TAT Te ett 


Application has generated an exception that could not be handled. 
Process idz0x69c (1692), Thread idz0x72c (1836). 


Click OK to terminate the application, 
Click CANCEL to debug the application. 


terei 


Z A HELLO.EXE futása - vagy halála. A második futásnál 
lefagyott 


Ehhez mindössze annyit kell tudnunk, hogy az inputparaméte- 
reket a Main() függvény veszi át, mégpedig egy stringtömbben. 
Nincs más dolgunk, mint nevet adni a stringtömbnek (a mi ese- 
tünkben szoveg lesz a becses neve), és máris dolgozhatunk ve- 
le (a tömbök nullától indexelődnek). Itt a forráskód a maga tel- 
jességében, tegyék bele egy .CS kiterjesztésű textfájlba, majd 
fordítsák le a CSC.EXE segítségével. 






class echo ( ép 
static void Ma. 
9E/ ie 





System.Conso; 
5 ÉTÉ 


Ez a kód - egyelőre — több logikai hibát is tartalmaz, sőt, néha 
fejreáll. Ebben az állapotban nem nevezném végleges verzió- 
nak, hiszen két esetben is hibázik: 
TA ha egyáltalán nem adunk meg inputparamétert, lefagy 
HA ha egynél többet adunk meg, a többire rá sem hederít 








Mindkét hibatípus elhárítható, ha figyelembe £] 
vesszük, hány inputparamétert kapunk valójában. A a) 


szoveg nevű stringtömbnek van egy .Length tulajdon- 

sága, amiből kiolvasható, hány elemű a tömb. Az 

adatok kiírásába csak akkor kezdjünk bele, ha lega- 

lább egy inputparaméterünk van. Ezt egy egyszerű feltételes 
utasítással fogalmazhatjuk meg: 


if (szoveg.Length : 0) 

jé B 
System.Console.WriteLine(szoveg[0]); 

, 


Most már lefagyástól nem kell tartanunk, de még mindig elve- 
szítjük a második, harmadik és sokadik inputparamétert. Ennek 
elhárítása a következő módon történhet: a szoveg stringtöm- 
böt, mint kollekciót ,bejárjuk", azaz kiszedegetjük belőle az 
összes gyermekelemet. Ehhez a foreach bejáróciklust használ- 
hatjuk. Tulajdonképpen ez az ,univerzális" megoldás, mert 
nulla elemű kollekcióra is helyesen működik, nincs is szükség 
az előbbi if-re: 


foreach (string duma in szoveg) 
d ki 
System.Console.WriteLine (duma ) ; 
3 


Az így elkészített , alkalmazás" már az összes inputparamétert 
feldolgozza" — vagyis kiírja a képernyőre: 


WINDOWSISystem321cmd.exe 





E A hibátlan HELLO.EXE az összes bemenő paraméterét 
kiírja 


A .NET keretrendszer felfedezése 


Most evezzünk egy picikét más vizekre, hagyjuk félbe a 
HELLO.CS alkalmazást, s nézzük meg, milyen szolgáltatásokat 
kínál a .NET keretrendszer. Ehhez egy ingyenesen letölthető se- 
gédeszközre lesz szükségünk, ez a .NET Reflector (letölthető a 
[reflector] címről). 

Ez az eszköz a hivatalos dokumentációt helyettesíti számunk- 
ra (amelyet egyébként MSDN-nek hívnak), megmutatva a 
.NET-keretrendszer objektumhierarchiáját. A Reflector tulaj- 
donképpen  visszafejti a lefordított  rendszer-DLL-ek 
(assemblyk) kódját. De nem hackermódszerekkel, hanem legá- 
lisan: az úgynevezett Reflection eljárás segítségével, ami a 
DLL-ekben meglévő információk visszafejtéséhez tartozó beé- 
pített .NET-technológia. Objektumnév szerinti keresésre is ké- 
pes, tehát ha csak félig, vagy alig tudjuk, mit keresünk, a 
Reflector akkor is jó szolgálatot tesz. Letöltés után — jó .NET-es 
szokás szerint — nem kell telepítést végezni, csak zippeljük ki 
valahova, és egyszerűen indítsuk el! Az alábbi ábrán például a 
szövegkiíratáshoz használt Console objektum első néhány me- 
tódusa látszik. 
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NET-et a rendszergazdáknak! 


£7 Lutz Roederis .NET Reflector 





7 I mscortb A 
5 n 
Hi Ca Dependencies 
0 - 
A ( Microsoft.Win32 
2 (0 System 
§ 2g  Comobject 
€ 20 ApbDomain 
F 0g Actívator 
§ 9 AppDomain 
8 0 AppDomainSetup 
a 98 cLscompliantáttribute 
z 98 Console 
40 BaseTypes 
4 Cs SubTypes 
79 OpenstandardError() : Stream 
16 Openstandarderror(Int32) : Stream 
99 Openstandardinput() : Stream 
79 Openstandardínput(Int32) : Stream 
79 Openstandardoutput() : Stream 
79 OpenstandardOutput(Int32) : Stream 


3 A Reflector rávilágít a .NET-keretrendszerre 


A WriteLine() metódus nem fért ki a képre, de ha 
lejjebbgörgetünk, megtaláljuk. Sőt, nem is egyet találunk, ha- 
nem egy egész seregnyit! Egy-egy WriteLine() tartozik minden 
egyes kiírandó alap-adattípushoz. 

Ennek a jelenségnek szakszerűen az a neve, hogy Over- 
loading, és az a szerepe, hogy a közel azonos funkciót ellátó 
metódusok azonos néven szerepelhessenek, ne kelljen verzió- 
számmal ellátott csúnya burjánzást alkotni ilyen esetekben. 
Ha rákattintunk egy metódusra, az alsó sávban megjelenik an- 
nak pontos használata. Egy WriteLine esetében nem sok kétség 
merülhet fel a bemenő paraméterek sorrendjét és használatát 
illetően, bonyolultabb esetekben azonban igencsak jól jön ez 
a segítség. Később látunk is rá példát. 


£ Lutz Roederis, .NET Reflector, 
Ele  Wiew Languages  Iools Help 
99 3 PA 4-M- 
76 write(Uinté4) : void 
79 writeline() : Vold 
70. Writeline(Boolean) : Void 
76 writeline(Char) : void 
79 Writeline(Char[(]) : Void 
79. Writeline(Char(], Int32, Int32) : void 
269 Writeline(Decimal) : Vold 
79. writeline(Double) : Void 
99 writeline(Int32) : Void 
79 Wwriteline(Inté4) : Void 
79 Writeline(Object) : void 
769. writeline(Single) : void 
70 TIETZEZTEZTT 
99 writeline(String, Object) : void 
79 writeline(String, Object, Object) : void 
79. Writeline(String, Object, Object, Object) : Void 
709 writeline(String, Object, Object, Object, Object, ...) : Void 
709 Writeline(String, Object[]) : void 
76 Writeline(llnt32) : Void 
79 writeline(Ulinté4) : void 
4 161 Error : TextWriter 
4 961 In : TextReader 
4 961 Out : TextWriter 
. S8b Contextgoundobject 








! public static void WriteLineístrng value); 
Flags: IL Managed 





Az előbbi ábrán a kijelölés pontosan az általunk használt 
WriteLine() változatot mutatja. Kezünkben a felderítési eszköz, 
most már csak értelmes feladatot kell találnunk. Mi lenne, ha 
megvalósítanánk a SendMail.EXE programot, ami a parancs- 
sorból átvett adatok birtokában SMTP levelet küld? 


SENDMAIL.EXE készítése 


Először is meg kellene találnunk azt az objektumot (és annak 
megfelelő metódusát), ami a levélküldést elvégzi nekünk. Ke- 
ressünk rá erre a szóra (F3): ,mail". Az alábbi ábrán láthatjuk 
a találatok rövid listáját: 








Type Search 

mail 
Type Namespace 

98 smtprail System. web.Mail 
aPMailFormat Systern.web.Mail 
sPMailPriority System. web.Mail 
EP MailEncoding Systern.web.Mail 
Pe mailattachment System.web.Mail 
9g MailMessage System.web.Mail 


E A Reflector pásztázásának eredménye a ,,mail" szócs- 
kára 


Legszimpatikusabb találatnak a legelső tűnik. Megfigyelhető, 
hogy az összes találatunk a System.Web.Mail névtérből szár- 
mazik. Ha bármelyik találaton kettőt kattintunk, a Reflector 
odarepít minket. Ebben a névtérben laknak tehát a levelezéssel 
kapcsolatos objektumok. Ha kinyitjuk az SmtpMail objektu- 
mot, meglátjuk a metódusait. Két Overloadolt Send() áll előt- 
tünk, az egyik egy MailMessage típusú objektumot vár beme- 
netként, a másik pedig négy stringet. Ezek nyilván a címzett, 
tárgy, feladó stb. mezők — de vajon melyik-melyik? Kattintsunk 
csak a négyparaméteres Send0-re! 


4 () System.Web.Hosting 
2 () System.web.Mai 
4 7g Malattachment 
4 4? MallEncoding 
4 AP MallForrnat 
4 0g MalMessage 
4 AP MalPriority 
7 0£ Smtpmail 
810 Base Types 
a Ca Sub Types 
79 Send(MailMessage) : void 


TF () System.Web.Security 





public static void Sendéstring from, string to, string subject, string 
messageText); 


Flags: IL Managed 





E A Reflector rávilágít a Send() metódus bemenő para- 
métereinek szerepére 


Az alsó sávban leolvashatjuk, hogy a paraméterek rendre from, 
to, subject és messageText. A Send() metódus alatt pedig egy 
propertit látunk, melynek SmtpServer a neve: mielőtt levélkül- 
désre kerülne sor, be kell állítani a használni kívánt SMTP- 
kiszolgáló nevét vagy címét. 

Így kell tehát használni: 


using System.Web.Mail; //a használni kívánt névtér 
class level 
8 
static void Main() 
( 
SmtpMail .SmtpServer - "mail.encegem.hu"; 
SmtpMail.Send("feladoeceg.hu", "cim€ceg.hu", 
b "targy", "szoveg"); 
3 
J 


Persze ez egy teljesen ostoba kód, hisz egyrészt az égvilágon 
minden bele van drótozva, másrészt nem teng túl benne a hi- 
bakezelés, de úgy vélem, az átláthatóságot nagyban segíti, ha 
csupán a lényeget mutatom meg. A NetAcademia Tudástárban 
elhelyeztem ennek a programnak azt a változatát, amely min- 
den paraméterét parancssorból veszi. 

Egy kis újdonság is található a fenti kódban, mégpedig az using 
direktíva. Ennek megadásával mentesíthetjük magunkat a 
névterek állandó megadásától. 


using System.Web.Mail; //a használni kívánt névtér 


Emiatt használhattuk simán, rövid névvel az SmtpMail objek- 
tumot. 


Írjunk az Event Logba! 


Látványos hatást érhetünk el, ha futtatott batch-eink a hibaüze- 
neteket a Windows Eseménynaplóba írják. A .NET-keretrend- 
szer megjelenése előtt ehhez mindenképpen Windows API-hí- 
vásra volt szükség, emiatt csak a legmegátalkodottabbak vete- 
medtek ilyesmire. A keretrendszer megjelenésével ez az áthág- 
hatatlan akadály eltűnt az utunkból. 

Keressünk rá a Reflectorral erre a szóra: ,eventlog". A találatok 
a System.Diagnostics névtérben laknak, ezek közül válasszuk 
az EventLog objektumot. Kitt-katt! 

Ezzel már nincs akkora szerencsénk, ugyanis ebből az objek- 
tumból mindenképpen új példányt kell szülni: 


EventLog beir - new EventLog(); 


A beir nevű objektumváltozó mögött egy olyan objektum la- 
pul, amelyik már közvetlenül képes eseménynapló-műveletek- 
re. Ehhez először meg kell adnunk, ,ki" is ír a naplóba: 


beir.Source-"Logolo Alkalmazas"; 


És már jöhet is egy jó kis hibabejegyzés: 








beir.Wr: iteEr ry("jajajajaj!", 
b EventLogEntryType.Error); 


Az eredmény önmagáért beszél: az adott gép Application 







































Application 109 eventís) eleg 
[Type [Date I Time Source [ca a 13 he 
JDeror 2003.06.18. — 15:46:15 — Logolo álkalmazas No 
DError 2003.06.18. 15: asdasd No [7 
Áirformet áz ege en PGA EESzEtRTNTÉS ni 
ESZE Event Properties 
DError 
A warning 
DEnor Date: Source:  Logolo Alkalmazas ps 

Error Time: 15:46:15.— Category: None 
es Type: Enor EventID: 0 § 

rror 

User NZA 
DError 
Computer: WINXP-MARCI 

Error 
Derror Description 
DError isis 

Error 
ÉJ Error For more informati Help and Support Center at 
Örrror http.//g0 microsoft comzfulink events asp. 





5 Sikeresen beleírtunk az Event Logba! 


Ha én Önök lennék, utánanéznék a WriteEntry() második pa- 
raméterének, vajon mi mást lehet ott még megadni? Ez a para- 
méter EventLogEntryType típusú. Ha rákeresünk, kiderül hogy 
ez egy úgynevezett Enum, vagyis névvel ellátott konstansok 
gyűjteménye. A következő értékei vannak: 

A Error— 1 

A FailureAudit — 16 

A Informatio — 4 

A SuccessAudit — 8 

A Warning - 2 


További jó kísérletezést kívánok! 


Fóti Marcell 

marcellfenetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 
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Portál Paraldigmal — DU. 


Network Load Balancing Services: 
24 órájában 


elérhető portál szolgálatában 


Manapság naponta hallhatunk híreket új portálszolgáltatások születéséről, és régebbiek megszűnésé- 
ről. A sikeres portál hasznos információkkal látja el látogatóit, szolgáltatásait egyre többen és gyakrab- 
ban veszik igénybe. A legsikeresebbeket sok ember elsődleges hírforrásként használja, vagy szolgálta- 
tásainak használatával végzi mindennapi munkáját. Azonban még egy ilyen népszerű és nagy látoga- 
tottságú portáltól is könnyen elpártolhatnak a felhasználók, ha gondok merülnek fel a kiszolgálók elér- 
hetőségében, ha a szolgáltatások akadoznak, vagy ha a rendszer kényelmetlenül lassúvá válik. És is- 


mét jön a portál para. 


Egy portálrendszerrel szemben rengeteg igény merülhet fel a 
különféle felhasználók részéről. A végfelhasználók számára a 
tartalmon kívül talán a legfontosabb a szolgáltatások megbíz- 
hatósága és nagy rendelkezésre állása, a kiszolgálók gyakorla- 
tilag állandó elérhetősége, valamint a megfelelő sebességű mű- 
ködés. Az üzemeltetés feladata mindezt biztosítani, és érthető 
igényként merül fel erről az oldalról a megvalósítás és a kar- 
bantartás minél egyszerűbb és biztonságosabb módja. A portál 
tulajdonosainak célja pedig a felhasználói igények maradékta- 
lan kielégítése, valamint az üzemeltetés költségkímélő megva- 
lósítása. Az NLBS technológia megoldást nyújt ezen elvárások 
legtöbbjére. 


Mi is az NLBS? 


Szó szerint: hálózati terhelés-kiegyensúlyozó szolgáltatások. 
Kicsit bővebben egy olyan rendszer, amelyben egy szolgálta- 
tást több kiszolgáló lát el úgy, hogy a felhasználó számára ez 
egy virtuális hozzáférési ponton látszik, és a kiszolgálók száma 
és prioritása gyakorlatilag szolgáltatás-kiesés nélkül változtat- 
ható. 





3. hítp./wwnlbs.huindex himi 
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Felhasználó 5. Ponyvaregény 


NLBS Clustér 


E Portálmegoldás NLBS alkalmazásával 


Ha az életből kellene hasonlatot keresnem, talán egy telefonos 
ügyfélszolgálathoz hasonlítanám. Ebben az esetben legyen pl. 
a telefonos buszmenetrend-információ a szolgáltatás tárgya. 

":NLBS nélküli" esetben van egy telefonszám (a hozzáférési 
pont), amin a szolgáltatást el lehet érni, és van Mancika, (a ki- 


szolgáló), aki a telefon mellett ül, és fogadja a hívásokat. Ren- 
des körülmények között Mancika szépen ellátja a feladatát, és 
válaszol a menetrenddel kapcsolatos kérdésekre. Feltételezzük 
rendszerünkben, hogy a telefonszám mindig elérhető, műkö- 
dik a vonal (ISP feladatai), valamint a menetrendadatok is min- 
dig rendelkezésre állnak Mancika számára (adatbázisszerver 
rendelkezésre állása, elérhetősége). Azonban bizonyos nehéz- 
ségekkel számolnunk kell: 


A Mancikánk tragikus hirtelenséggel elhalálozik (a szer- 
ver fizikai megsemmisülése): ez nagyon súlyos problé- 
ma, hiszen sürgősen új alkalmazott után kell néznünk 
(hardverbeszerzés), aki betanítás (konfigurálás, adatfel- 
töltés) után képes elvégezni Mancika munkáját. 
Mindez jelentős szolgáltatás-kiesést okoz. 

A Mancika megbetegszik (szerverösszeomlás): ez is elég 
nagy probléma, hiszen ameddig nem gyógyul meg (hi- 
baelhárítási idő), addig szolgáltatásunk nem üzemel 
(szolgáltatás-kiesés). Esetleg megoldhatjuk úgy a prob- 
lémát, hogy a feladatra ráállítjuk Gizikét (elfekvő gép a 
sarokban), aki amolyan mindenes a cégnél, van ideje 
felvenni a telefont, viszont nyilván csak kisebb haté- 
konysággal vagy minőségben képes elvégezni ezt a 
munkát (gyengébb hardver). És még ekkor is időbe te- 
lik, mire ő munkába tud állni, hiszen el kell neki ma- 
gyarázni, hogy hogyan beszéljen az ügyféllel, hol talál- 
ja meg a menetrendadatokat, stb. (konfigurálás, adatfel- 
töltés). 

A Mancika ebédelni megy (szerverkarbantartás): ekkor 
rövid kiesés lehet a szolgáltatásban, amit még általában 
elviselnek a felhasználók, de jobban örülnének, ha 
nem lenne ilyen. 

JA Mancika elájul (alkalmazáshiba): a problémát nehéz 
detektálni, hiszen Mancika nem tud szólni, hogy elá- 
jult. Ám amikor Bözsike, a főnök (rendszergazda) épp 
ellenőrizni akarja, hogy Mancika dolgozik-e rendesen 
(monitorozás), észreveszi, hogy problémák vannak ve- 
le (hibadetektálás). Kis vizsgálódás után rájön, hogy 
Mancika valószínűleg eszméletét vesztette (hibaazono- 
sítás), viszont megoldást nem tud rá, ezért orvost (szak- 
értő) hív, aki a problémát megoldja (hibajavítás): vizet 


önt rá és felpofozza. Mindez természetesen időbe telik, 
ami lehet több-kevesebb, de ha pl. épp csúcsidőben 
történik, az ügyfelek számára elég lehangoló lehet a 
szolgáltatás-kiesés. 

HA Mancika éppen beszél egy ügyféllel, ezért más ügyfe- 
leknek várakozniuk kell (rendszerterheltség, hosszú vá- 
rakozási idők): egy-két esetben még kibírja az ügyfél, 
de harmadjára már türelmetlenné válik, és inkább ke- 
res másik forrást az információ beszerzésére, elégedet- 
len lesz a szolgáltatással, és sajnos a felmérések szerint 
tíz emberből kilenc ezt a benyomását tovább is adja is- 
merősei felé. 


Nézzük meg ezek után, hogy egy ,NLBS-t alkalmazó" rend- 
szer hogyan kezeli vagy védi ki ezeket a problémákat. A rend- 
szer felépítése kicsit komplexebb, mint az előző esetben. Man- 
cika mellé felveszünk még egy munkaerőt: Pirikét (kiszolgáló). 
Mindketten kapnak egy-egy telefont (hozzáférési pont). Telepí- 
tünk egy telefonközpontot (NLBS), aminek az a feladata, hogy 
a régi telefonszámra (virtuális hozzáférési pont) jövő hívásokat 
a konfigurációnak megfelelően irányítsa Mancika illetve Pirike 
telefonjára. A telefonok kikapcsolhatóak, ekkor a telefonköz- 
pont nem irányít rá hívásokat. A telefonközpont érzékelni tud- 
ja azt is, ha meghibásodott egy telefon, és akkor szintén nem 
irányít rá hívást. Valamint a telefonközpont bővíthető, újabb 
telefonok köthetők rá úgy, hogy a működésben ez nem jelent 
kiesést. 

Mit tapasztal ilyenkor az ügyfél? Lényegében első körben sem- 
mit. A szolgáltatás ugyanazon a telefonszámon érhető el. Bár 
néha Mancikával beszél, néha pedig Pirikével, de neki ez nem 
tűnik fel, mert mindkettő kedves női hang. Nézzük meg, hogy 
mi a helyzet ekkor az első eset problémáival: 


H Mancika tragikus hirtelenséggel elhalálozik (szerver fi- 
zikai megsemmisülése): ennek a problémának súlyos- 
sága nem csökken az előző esethez képest, azonban 
hatása jóval kisebb, hiszen Pirike még mindig végzi a 
munkáját, és így az ügyfelek semmit nem vesznek ész- 
re a problémából, maximum azt, hogy ezáltal kicsit 
többet kell esetleg várakozni a hívásfogadásra. Tehát 
szolgáltatás-kiesés nincs, a rendszer viszont terhelteb- 
bé válik. 

H Mancika megbetegszik (szerverösszeomlás): a helyzet 
ugyanaz, mint az előző esetben, a probléma az ügyfe- 
lek felé csak teljesítménycsökkenés formájában jelenik 
meg. 

H Mancika ebédelni megy (szerverkarbantartás): ekkor 
rövid teljesítménycsökkenés lehet a szolgáltatásban, 
amit az ügyfelek általában észre sem vesznek. 

TH Mancika elájul (alkalmazáshiba): miután észreveszik, 
hogy Mancika elájult, kikapcsolják a telefonját. Addig 
sajnos csörög, vagy foglaltat jelez, és bosszanthatja az 
ügyfeleket, de a kiiktatás után a szolgáltatás csökkentett 
teljesítménnyel Pirike által működik tovább. 

HA Mancika éppen beszél egy ügyféllel, ezért más ügyfe- 
leknek várakozniuk kell (rendszerterheltség, hosszú vá- 
rakozási idők): nem kell várakozniuk, hiszen Pirike is 
tudja fogadni a hívásokat. 


Az NLBS tehát hasonló szerepet játszik egy szerverfarm műkö- 
désében, mint a fenti példában a telefonközpont. Kicsit sántít 
azonban a példa abból a szempontból, hogy a telefonközpont 





meghibásodása az egész rendszer hibáját okozza, 
míg az NLBS egy elosztottan működő rendszer, és 
ennél fogva csak akkor hibásodik meg, ha minden 
eleme hibássá válik. 

A példa viszont azt hiszem, jól rámutat a lényegre, 
mégpedig arra, hogy egy ilyen rendszert használva a problé- 
mák száma és súlyossága nem csökken ugyan, de a felhaszná- 
lók mindebből szinte semmit se érzékelnek, és szolgáltatásaink 
működőképesek maradnak. És úgy gondolom, hogy az ilyen 
működés nagymértékben hozzájárulhat egy portál sikerességé- 
hez. 


Az NLBS egy elosztott rendszer 


Szervereinket fürtbe szervezhetjük (akár 32-t is), ekkor minden 
fürttagon fut egy NLB driver, ami a hálózati kártya és a TCP/IP 
kernel szintű driver-ek közé egyfajta szűrőként épül be. Mivel 
minden szerveren fut NLB driver, nincs Single Point Of Failure 
(SPOP), azaz a rendszer addig működőképes, amíg legalább 
egy tagja működik. 


Custer Host 1 (Custer Host 2. Custer Host 32 
Szerver Szerver 


Alkalmazás Alkalmazás. 


Windows Kernel 
TCPAP 


Windows Kernel 
TCPAP ! 


MCOrver ] 


Virtuális IP: 10.0.0.5 
Dedikált IP: 10.0.0.11 


Virtuális IP: 10.0.0.5 
Dedikált IP: 10.0.0.10 
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E Az NLBS architektúrája 


Minden fürttag rendelkezik minimum egy dedikált és egy vir- 
tuális IP-címmel. A dedikált IP arra való, hogy a fürt egyes tag- 
jait egyedileg, külön-külön is meg lehessen címezni, el lehes- 
sen érni (például adatfeltöltés céljából). A virtuális IP pedig a 
közös elérési pont, ahol a szolgáltatások egy külső gép számá- 
ra hozzáférhetőek. Fontos dolog, hogy szerverfarm tagjai nem- 
csak közös IP-címmel, hanem egy közös MAC-címmel is ren- 
delkeznek. Ez biztosítja, hogy a hálózat adatkapcsolati szintjén 
(Layer 2) is egy címen érhető el a cluster minden tagja. Így te- 
hát egy a farmnak címzett csomag mindig eljut a farm minden 
aktív tagjához, legyen szó akár Ethernet (frame), akár TCP/IP 
(packet) csomagokról. 


Unicast/Multicast 


Az NLBS fürtünk működhet Unicast vagy Multicast módban. 
Az előbbi esetben a fürt tagjai egy közös MAC-címet használ- 
nak, és minden dedikált és virtuális IP-címet is erre a közös 
címre fordítanak egy ARP kérés esetén. (Az ARP és a RARP az 
IP-cím — MAC-cím összerendeléseket felderítő protokollok.) 
Ekkor tehát nem lehet megkülönböztetni szervereinket MAC- 
címük alapján (legalábbis az NLBS-t használó hálózati kártyán 
keresztül nem). Multicast módban a hálózati kártyák MAC- 
címei megmaradnak, és a dedikált IP-címek ezekhez rendelőd- 
nek, a virtuális IP-címhez pedig egy másik MAC-cím rendelő- 
dik, ez lesz a közös Multicast MAC-cím. Ennél a konfiguráció- 
nál a szerverek a dedikált IP-címeken és a hálózati kártyák 
egyedi MAC-címén keresztül különböztethetők meg és érhetők 
el (pl. be lehet terminálozni rájuk külön-külön). Hátránya az 
utóbbi megoldásnak, hogy ún. switch-flooding veszélyt rejt 
magában, a sok Multicast-os csomag miatt switchünk működé- 
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se közelíthet (sajnos) egy hub működéséhez. Ráadá- 
sul bizonyos aktív hálózati eszközök nem tudják au- 
tomatikusan kezelni a Multicast címzést, kézi beállí- 
tásokra lehet szükség. Ezek miatt elsősorban a 
Unicast mód használata ajánlott, hacsak nincs vala- 
mi olyan követelmény a rendszerrel szemben, ami ezzel nem 
oldható meg. 


Portszabályok (Port Rules) 


Szabályokat hozhatunk létre abból a célból, hogy megadjuk, 
szerverfarmunk milyen IP-címekre és portokra hogyan reagál- 
jon, milyen protokollok használatát engedje (TCP/UDP/mind- 
kettő), milyen szűrési módot akarunk alkalmazni, valamint 
hogy a terheléselosztást milyen affinitással és súlyokkal szeret- 
nénk megvalósítani. 


Add/Edit Port Rule KkiEi 


f Cluster IP address 





168. 0.220 or [7 Al 




















T Port range 
From: o 4 Tao: [85535 z4 
T Protocols 
CICP CC UDP CG Both 
Tr Filtering mode 
(5 Multiple host Affinity C None CG Single C ClassC 
Loadweight [E 4 or [7 Egual 
C Single host Handling priority: n 2 








€ Disable this port range 








Cancel I 





E Portszabályok beállítása 


Megtehetjük, hogy bizonyos szolgáltatásokat csak bizonyos 
IP-címeken teszünk elérhetővé, míg másokat pl. a fürt minden 
IP-címén. A szűrési módok közül a tiltás (Disable this port 
range) értelmezése egyértelmű, az ebbe a módba állított por- 
tokra jövő kéréseket a farm tagjai figyelmen kívül hagyják. A 
,Single host" mód esetében a kéréseket mindig egy kiszolgá- 
ló szolgálja ki, mégpedig az, amelyiknek az aktív szerverek 
közül legnagyobb a prioritása, azaz a , Handling priority" pa- 
raméterének értéke a legkisebb. Ha a ,Multiply host" szűrést 
választjuk (a legtöbb esetben ez a célszerű), a terhelés elosz- 
lik a kiszolgálók között, mégpedig a beállított súlyok (Load 
Weigh1) szerint. Az alapbeállítás esetén ez egyenletes (Egual) 
terheléselosztást jelent, amit akkor érdemes alkalmaznunk, ha 
a szervereink körülbelül azonos kiszolgáló-kapacitással (CPU, 
memória, stb.) rendelkeznek. Ha vannak erősebb és gyengébb 
gépeink is a szerverfarmunkban, érdemes úgy beállítani a ter- 
helési súlyokat, hogy a robosztusabb szerverekre arányosan 
nagyobb terhelés jusson. Az affinitás konfigurálásánál három 
lehetőségünk van: ,None", , Single", , Class C". Az első ered- 


ményezheti a leggyorsabb működést: ilyenkor az ugyanattól a 
klienstől érkező kéréseket akár több szerver is kiszolgálhatja, 
ami bizonyos fokú párhuzamos működést jelenthet. Nagy hát- 
ránya ennek a beállításnak, hogy session-ök (állapottal rendel- 
kező kapcsolatok) vagy IP-csomag-fragmentáció (UDP eseté- 
ben) kezelésére nem alkalmas, hiszen ezekben az esetekben 
elengedhetetlen, hogy minden kérést/csomagot ugyanaz a 
szerver szolgáljon ki. Az affinitás másik két módja erre a prob- 
lémára megoldást nyújt. , Single" módban ugyanarról az IP- 
címről jövő kérésekre mindig ugyanaz a szerver válaszol. 
,Class C" módban pedig ugyanarról a C-osztálybeli alhálózat- 
ról érkező kéréseket kezeli mindig ugyanaz a kiszolgáló. 
(Azok a kliensek tartoznak egy C-osztályba, amelyek IP- 
címeinek első három tagja megegyezik, pl.: a 10.0.0.100 és a 
10.0.0.200 egy C-osztályba tartozik, de a 10.0.2.100 már egy 
másikba.) 


A szívverés (Heartbeat) és a konvergencia (Convergence) 


A ,szívverés" protokoll az alapja a fürttagok egymás közötti 
kommunikációjának. Minden szerver másodpercenként ki- 
küld egy csomagot mindenki számára, ami körülbelül így néz 
ki: ,Én, az 1-es szerver vagyok, élek, és jól vagyok, köszönöm 
szépen!". Pont ugyanúgy, mint egy jól működő szív, rendsze- 
resen, egy meghatározott ütem szerint küldi ezeket az üzene- 
teket; innen jön az elnevezés. Felvetődik a kérdés, hogy nem 
okoz-e nagy hálózati forgalmat ez a protokoll, de mivel gé- 
penként és másodpercenként 1 db csomagról van szó, meg- 
nyugodhatunk, hogy nem. 

A konvergencia tulajdonképpen a szerverek NLBS beállításai- 
nak egyeztetése. A folyamat során kiderülhetnek különféle hi- 
bák, például ha nem ugyanúgy állítottuk be az egyes fürttago- 
kat. Vagy ha új fürttag jelenik meg, vagy éppen kiesik egy, a 
terheléselosztás súlyai módosulnak, és ezek végleges értékei- 
nek kialakítása illetve a beállítások elterjesztése minden szer- 
verre szintén a konvergencia során valósul meg. A konvergen- 
cia tehát az NLBS-fürt állapotváltozásakor elinduló folyamat, 
ami a fürttagok limitált számú üzenetváltása után a fürtöt egy 
új, konzisztens állapotba viszi. Ez az állapot a fürt szerverei- 
nek konszenzusakért alakul ki, és ezután minden aktív kiszol- 
gáló az új állapot szerint működik tovább. A konvergencia-fo- 
lyamat elkezdéséről és eredményéről naplóbejegyzés is ké- 
szül a rendszernaplóba. 


A működés algoritmusa 


Tekintsük át a klienskiszolgálás folyamatának lényegét egy 
HTTP-kérés esetében! 


ti 





Munkaállomás 
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NLBS Web Szerver Farm 


Virtuális IP: 10.0.0.5 HeartBeat 











WebSrvt WebSrv2 kt WebSrv4 


Dedikált IP: 10.0.0.10— Dedikált IP: 10.0.0.11 WebSrv3 Dedikált IP: 10.0.0.13 
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Karbantartás 
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5 Egy Webszerver-farm lehetséges felépítése 


1. A kliens HTTP kérést küld a szerverfarm virtuális IP- 
címére (10.0.0.5). 

2. Ezt a kérést minden aktív kiszolgáló megkapja 
(Websrv1, Websrv2, Websrv4, a Websrv3-on ugyanis 
éppen biztonsági javításokat telepítenek). 

3. Az NLBS stabil állapotban van, ezért minden egyes 
szerver az NLBS állapot-paraméterek és portszabályok 
alapján eldönti, hogy neki kell-e kiszolgálnia a kérést, 
vagy sem. 

4. Ha neki kell, kiszolgálja a kérést. Ha nem, nem csinál 
semmit. 


Megjegyzendő, hogy az elosztott működés erőssége az, hogy 
minden fürttag ugyanolyan bemenő paramétereket felhasznál- 
va (, shared view" az NLBS aktuális állapotáról) ugyanolyan al- 
goritmus alapján ugyanazt a döntést hozza, miközben az egy- 
mással való kommunikációra nincs szükség! Tehát a működés 
független egymástól (ezért nem baj, ha kiesik valamelyik szer- 
ver), és a döntés mégis megegyezik (nincs konfliktus: nincs 
olyan, hogy egy kérést két szerver próbál kiszolgálni). 

Nézzünk meg ezek után egy esetet a konvergenciára: 


1. A mostani stabil állapotban három aktív szerverünk 
van, melyek jelenlegi terhelési súlyai a következők: 
Websrv1 — 2099, Websrv2 — 2099, Websrv4 — 6099. 

2. Befejezzük a Websrv3 karbantartását (pl. memóriát tet- 
tünk bele). 

3. Aktív állapotba állítjuk a Websrv3 gépet, ami egy kon- 
vergencia-folyamatot indukál. 

4. A konvergencia eredménye négy aktív gép lesz, új ter- 
helési súlyokkal (amelyek jelen esetben megfelelnek a 
beállított értékeknek): Websrvi — 1090, Websrv2 — 
1099, Websrv3 — 5099, Websrv4 — 3090. 


A működés hatékonyságára jellemző, hogy egy kieső gépet 5 
másodperc múlva detektál a rendszer, és ezután körülbelül to- 
vábbi 5 másodperc szükséges a konvergencia lezajlásához. Így 
pl. egy szerverösszeomlás esetén mindössze 10 másodperc kri- 
tikus időszak van, ami alatt esetleg történhetnek kiszolgálatlan 
kérések. 





Az NLBS erősségei ú..! 
Vizsgáljuk meg közelebbről, milyen előnyös tulaj- ez 
donságokkal rendelkezik az NLBS: S 


Magas rendelkezésre állási idő 


Az NLBS rövid idő alatt képes: 

FA automatikusan detektálni és eltávolítani a fürtből egy 
meghibásodott vagy kikapcsolt (offline) szervert, 

A automatikusan detektálni és hozzáadni a fürthöz egy 
megjavított vagy elérhető (online) állapotba került szer- 
vert, 

FA automatikusan újrakonfigurálni a rendszer terhelés- 
elosztását a fürt állapotának változásai esetén (új szer- 
ver hozzáadása, szerverhiba stb.). 


Ha ,sokkilences" rendelkezésre-állásra van szükségünk, vagy 
szeretnénk, ha bizonyos hardverhibák, vagy karbantartások 
(pl. biztonsági javítások telepítése) ellenére a portál vagy egyéb 
szolgáltatásunk folyamatosan elérhető legyen, az NLBS alkal- 
mazása megoldást jelenthet. 

Skálázhatóság 

A Az NLBS képes több szerver közötti terheléselosztás 
megvalósítására. 

A Az NLBS fürtben lévő gépek száma igény szerint bár- 
mikor változtatható (maximum 32 szerverig fürtön- 
kény. 

A Az NLBS cluster gépei teljesen különbözőek is lehet- 
nek (akár jelentős teljesítmény-különbség is előfordul- 
hau. 


A skálázásnak alapvetően két módja van: a vertikális (felfelé) és 
a horizontális (oldalra) skálázás. Előbbi esetben a nagyobb tel- 
jesítmény érdekében több erőforrást (több és gyorsabb CPU-t, 
memóriát, diszket stb.) teszünk egy szerverbe, míg az utóbbi 
esetben, amit az NLBS is megvalósít, a kiszolgálók számát nö- 
veljük, és az elvégzendő feladatokat (egy portálnál tipikusan a 
látogatók kiszolgálásának feladatát) elosztjuk közöttük. Az 
utóbbi módszer teljesítményben lehet kicsit lassabb, technikai 
megoldása bonyolultabb, viszont hibatűrőbb és jóval olcsóbb. 
(1 db 4 processzoros, redundáns és hot-plug alkatrészekkel el- 
látott gép jóval drágább, mint 4 db 1 processzoros standard 
gép NLBS-be rakva, ami hasonló teljesítményt és hibatűrést 
nyújt.) 

Ha tehát olyan portált szeretnénk, aminél előfordulhat a láto- 
gatók számának erőteljes növekedése (márpedig ki ne szeretne 
ilyen portált?), NLBS használata esetén bármikor az igények- 
nek megfelelően és ugyanakkor költségkímélően tudjuk ská- 
lázni rendszerünket. 


Könnyű használat 


A A Windows2003 minden verziójának installálásakor az 
NLBS driver automatikusan felkerül a számítógépre. A 
Windows2000 Advanced Server esetében a hálózati 
meghajtóprogramok közül választható ki és telepíthető. 

JA Az NLBS nem támaszt semmiféle extra hardverigényt. 
(Ennek ellenére tapasztalatunk alapján például a 
Realtek 8139-es sorozat hálózati kártyáival nem műkö- 
dik. 9) 

A Az NLBS-kompatibilis szerveralkalmazások nem igé- 
nyelnek semmiféle konfigurációs változtatást, amikor a 
fürtbe rakjuk őket. 
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JA A karbantartások idejére könnyen és gyorsan offline ál- 
lapotba állíthatók a szerverfarm gépei, és ugyanígy 
vissza is rakhatók a munkálatok elvégzése után. 

JA A meghibásodott szervereket az NLBS detektálni tudja, 
automatikusan el tudja távolítani a fürtből, javításuk 
után pedig automatikusan vissza is tudja helyezni őket. 

HA Az NLBS szerverfarm a felhasználók felé egyetlen elé- 
rési ponton látszik, az esetleges meghibásodások, kar- 
bantartások, konfigurációs módosítások, a kiszolgálók 
számának változása a kliensek számára gyakorlatilag 
láthatatlan, maximum teljesítmény és sebesség terén le- 
het az eseményeket közvetve érzékelni. 

A Win2003-ban az NLB Manager segíti az üzemeltetők 
munkáját. Windows 2000 esetében csak a parancssori 
eszköz, a wlbs.exe érhető el. 

HA Az NLBS a rendszernaplóba készít bejegyzéseket a fon- 
tosabb eseményekről. 


Az egyszerű telepítés, konfigurálás, üzemeltetés több szem- 
pontból is fontos tényező. Egyrészt költségkímélő, hiszen ha 
kevés gond van a rendszerrel, egyszerű elvégezni a karbantar- 
tásokat, az üzemeltetés olcsóbb lesz, hiszen kevesebb szaktu- 
dás és idő kell a feladatok végrehajtásához. Másrészt a rend- 
szer jobb, megbízhatóbb lesz, hiszen az üzemeltetési feladatok 
elvégzésekor kevesebb lehetőség adódik a hibázásra, valamint 
egy hibás kiszolgáló még nem okozza a rendszer működéskép- 
telenségét, a javítási és karbantartási idők pedig nem jelente- 
nek egyben szolgáltatás-kiesési időket is. Harmadrészt min- 
denki jól érzi magát: a felhasználók azért, mert mindig elérhe- 
tik a rendszer szolgáltatásait, az üzemeltetők azért, mert 
könnyen el tudják végezni a munkájukat, a szponzorok vagy a 
tulajdonosok pedig azért, mert mindenki elégedett és a költsé- 
gek sem túl jelentősek. 


Mire NEM nyújt megoldást az NLBS? 


Először is azok az alkalmazások, amelyek nem NLBS kompa- 
tíbilisak, nem fognak jól működni egy NLBS clusterben (pl. 
globális ASP változókat használó portál). Az NLBS technoló- 
giája megköveteli, hogy minden fürttagon fusson egy példány 
a szerveralkalmazásból, amely független a többi példánytól. A 
közös adatok használatát vagy replikálással (minden szüksé- 
ges adat ott van minden gépen: ez általában csak statikus ada- 
toknál oldható meg, pl. HTML fájlok), vagy valamilyen külső 
szinkronizálással kell megoldani, például SOL szerverrel (amit 
szintén nem árt fürtözni, hogy mindig elérhető legyen). 

Ha az egyik gépünkön a szerveralkalmazásunk leáll, vagy mű- 
ködése hibássá válik, de egyébként a szerver jól működik, az 
NLBS nem tudja detektálni és a fürtből eltávolítani a problé- 
más szervert (mivel a gép folyamatosan küldi az életjeleket a 
többi kiszolgálónak). Az ilyen eseteket magunknak kell 
megoldanunk, például monitorozó programok írásával és al- 
kalmazásával, amelyek bizonyos eseményekkor offline mód- 
ba teszik a hibás gépet, valamint riasztást küldenek az üze- 
meltetőknek a történtekről. 

Az NLBS fürt állapotváltozásakor megszakadhatnak a felépí- 
tett kapcsolatok. Ez a tulajdonság a működéssel jár, de szeren- 
csére a konvergencia csak ritkán előforduló és rövid ideig tar- 
tó folyamat, ezért nem okoz nagy problémákat, legtöbbször a 
felhasználó észre sem veszi a kapcsolat újraépülését. 

Mi a teendő, ha kevés a 32 szerver? Hát attól tartok, Ma- 
gyarországon még jó ideig elég lesz ennyi szerver egy NLBS- 
be... De ha mégsem, elő lehet venni a jó öreg Round-Robin 


DNS-t. Ez azt takarja, hogy egy DNS-névhez több IP-címet 
rendelünk. Ebben az esetben az NLBS-eink virtuális IP-címeit. 
Így építhetünk pl. 2 db NLBS-t 32-32 gépből, és a két virtuális 
IP-címet ugyanazon névhez kötve gyakorlatilag egy 64 gépes 
szerverfarmhoz jutunk. Felmerül a kérdés, hogy minek az 
NLBS, ha DNS Round-Robinnal is meg lehet oldani a terhelés- 
elosztást? A válasz: azért, mert a DNS Round-Robin nem hi- 
batűrő: nem tudja detektálni a hibás szervert, ezért csak akkor 
működik jól a rendszer, ha minden szerver jól működik. 

A változások kezelése is lassú, hiszen a DNS-zónák elterjedé- 
séhez sok idő kell. Ezen kívül az NLBS más előnyökkel is ren- 
delkezik, mint már az eddigiekben olvashattuk (pl. a DNS 
Round-Robin csak egyenletes terheléselosztást tud biztosíta- 
ni). Viszont a két módszer kombinációja nagyon hatékony, 
megbízható, jól működő rendszert alkot. Érdemes itt megje- 
gyezni, hogy az NLBS teljesítménye körülbelül 6-8 gép 
fürtözéséig még közel lineárisan növelhető gépenként, de 
ezután a további gépek hozzáadása már egyre kevésbé javítja 
a teljesítményt. Ezért a 32 gépes korlátot gyakorlatilag senki 
sem használja ki, sokkal jellemzőbb például az 1 db 32 szer- 
veres NLBS helyett 8 db 4 szerveres NLBS alkalmazása, és a 
8 db NLBS közötti terheléselosztás DNS Round-Robinnal va- 
ló megoldása. 

Az NLBS nem tűzfal. Azaz attól, hogy hibatűrő a rendszer, 
még nem lesz biztonságos. Külön kell gondoskodnunk az 
NLBS farm gépeinek védelméről, pontosan ugyanúgy, mintha 
csak egy gépünk lenne (hiszen a felhasználó felé az NLBS egy 
kiszolgálóként látszik). A támadások elleni védekezés jelent- 
het a biztonsági beállításoktól kezdve a javítócsomagok rend- 
szeres telepítésén, a vírusirtó szoftverek használatán át a tűz- 
fallal való védelmen keresztül sok mindent, de ezeket a mó- 
dokat most nem célom tárgyalni. 


A Windows 2003 újdonságai 


A Windows 2003 NLBS-e néhány újdonsággal szolgál az elő- 
ző verzióhoz képest: 


HA Az NLBS minden Windows 2003 változat része (Win- 
dows 2000 esetében csak az Advanced Server tartal- 
mazza) 

Több NLBS Cluster lehetősége egy gépen 

Több virtuális IP-cím lehetősége egy NLBS fürthöz 
IP-címhez köthető portszabályok 

NLB Manager 
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Az előző Windows-verzió nagy hiányossága volt, hogy nem le- 
hetett egy gép több fürtnek is egyidejűleg a tagja. Ez most már 
lehetséges. Így az NLBS lehetővé teszi pl. olyan tűzfal építését, 
amely hibatűrő módon tud működni: pl. 2 db kétlábú ISA 
Server Array módban (2 külön NLBS-be rakva a FrontEnd illet- 
ve a BackEnd lábak). Vagy egy másik példa: több interfésszel 
(Intranet, Internet, Extranet) rendelkező portálszerver hibatűrő- 
vé tétele a Windows 2000 NLBS-sel csak részben lehetséges, 
hiszen csak egy NLBS-t definiálhatunk, és így két interfészünk 
hibatűrését másképp kell megoldanunk. A Windows 2003-ban 
ezek a problémák már nincsenek jelen. 

A Windows 2000 NLBS-hez csak 1 db IP-címet rendelhetünk, 
és a portszabályok az egész rendszerre vonatkoznak. E korlá- 
tok eltűntek a Windows 2003-as verzióban. Így pl. építhetünk 
olyan farmot, ami több SSL-es portált is szolgáltat (hiszen ezt 
csak több IP-címmel lehet megoldani az alapérték szerinti 
443-as porton), és akár azt is megtehetjük, hogy bizonyos sza- 


bályok minden kérésre érvényre jussanak, bizonyosak pedig 
csak egy konkrét IP-címre érkezőkre. 

Az NLB Manager segítségével a fürtök konfigurálása és moni- 
torozása is könnyebbé vált. Centralizált módon akár több fürt 
állapotát is nyomon követhetjük egyszerre, grafikus felületen 
menedzselhetjük  szerverfarmjainkat. Windows 2000-nél az 
eszköz nem használható, ott csak a hálózati kártyák tulajdon- 
ságainál tudjuk konfigurálni az NLBS-ünket. 

Load Balancing Manager [DII 
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E Az NLB Manager 


Ugyanakkor a wlbs.exe parancssori eszköz továbbra is elérhe- 
tő, csakúgy, mint az előző verzióban (pl. wilbs guery pa- 
ranccsal kérdezhetjük le az adott gép aktuális állapotát). 








a A wibs.exe 


Néhány jelentős újdonság ellenére a kompatibilitás megvan a 
Windows 2000 és Windows 2003 NLBS verziók között, lehet 
vegyes fürtöt építeni, de persze ekkor az újabb NLBS előnyei- 
ről le kell mondanunk. Sajnos az NLB Manager nem alkalmas 
a Windows 2000-es fürttagok kezelésére. 


Néhány hasznos tanács 


A Minden fürttagon ugyanúgy kell a portszabályokat 
beállítani (NLB Managerrel ezt el se lehet rontani). 

HA Csak TCP/IP protokollt használjunk, a többi hálózati 
protokollt távolítsuk el az NLBS-es hálózati kártyákról! 
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Zárszó 


Remélem sikerült egy képet vázolnom a Network Load 
Balancing Services képességeiről, és bemutatnom előnyös és 
hátrányos oldalait különböző nézőpontokból vizsgálva. Ter- 
mészetesen mint minden más témáról az informatika területén, 
az NLBS-ről is még ódákat lehetne zengeni, írásom tehát sem- 
miképp nem lehet teljes, de ha sikerült felkeltenem az érdeklő- 
dést a hibatűrő, nagy rendelkezésre-állású, elosztott és skáláz- 
ható rendszerekkel kapcsolatban, célomat már elértem, és úgy 
érzem, nem dolgoztam hiába. (Egyébként sem, mert engem ér- 
dekelt a téma, és most már sok mindent tisztábban látok, és si- 
került már összeraknom egy működőképes Win2003 NLBS-es 
ISA Array-t is... ) 

Szívesen veszem lentebb található e-mail címemre a kérdése- 
ket, véleményeket, és sok sikert kívánok az NLBS-hez minden- 
kinek! 


A TCP/IP tulajdonságoknál fel kell vennünk a 
dedikált és a cluster IP-címet is, de mindig a 
dedikált kerüljön az első helyre! 

Statikus IP-címeket használjunk! 
Használjunk legalább két hálózati kártyát, 
amikor csak lehet! 

Használjuk az NLB Managert, amikor csak lehet (nehe- 
zebb hibázni vele, könnyebb, gyorsabb a használata, 
mint egyesével állítgatni a gépeket)! 

Az NLB Remote Control funkciót csak akkor használ- 
juk, ha muszáj (még inkább akkor se)! 

A fürttagok saját paraméterei (dedikált IP-cím, Host ID 
stb.) legyenek különbözőek! 

Mind a virtuális, mind a dedikált IP-címeknek egy alhá- 
lózatból (subnet) kell származniuk! 

A Failover Cluster és NLBS nem fér meg egymás mel- 
lett egy gépen! 

Ha lehet, használjuk a Unicast módot (vagy nézzünk 
utána a Multicast mód helyes használatának)! 
Figyeljünk arra, hogy szerveralkalmazásaink futnak-e, 
amikor aktivizálunk egy kiszolgálót (mert ha nem, a 
hozzá került kérések kiszolgálatlanul maradnak)! 
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Funkcióalapú 
hozzáférésvezérlés 


. Windows Server 


2003 Authorization Manager 


A jogosultságállítás hagyományos módja az egyes erőforrásokon lévő joglisták megfelelő beállítása. 
Igen ám, de minél bonyolultabb egy alkalmazás, annál nehezebb, sőt egyenesen lehetetlen fájl- és 
egyéb alacsonyszintű jogokra bontani a hozzáférést. Elvontabb, magasabb szintű jogosultságkezelést 
tesz lehetővé a Windows 2003 Authorization Manager alrendszere. 


Ahhoz, hogy az alkalmazások elláthassák azt a feladatot, 
amelyért készítették őket, különféle műveleteket kell elvégez- 
niük, és felhasználójuk nevében hozzáférést kell szerezniük a 
szükséges rendszererőforrásokhoz. Ezen felül biztosítaniuk 
kell azt is, hogy a megfelelő jogosultság nélkül senki ne hasz- 
nálhassa ezeket az erőforrásokat. 

A Microsoft Windows NT, Windows 2000 és Windows XP 
operációs rendszerek ennek megvalósítására tartalmazzák azt 
a lehetőséget, hogy a rendszergazdák beállíthassák az egyes 
objektumokhoz való hozzáférésre, illetve a különféle rend- 
szerműveletekre vonatkozó jogosultságokat. 

A rendszer objektumközpontú azonosítási modellen alapul, a 
jogosultságokat az objektumokhoz tartozó hozzáférésvezér- 
lési listák (access control list, ACL) tartalmazzák. Minden 
rendszerobjektumhoz tartozik ACL, amely az adott objektum- 
ra vonatkozó jogok listáját tartalmazza. A modell kiválóan al- 
kalmas arra, hogy a jól meghatározott, állandó erőforrásokhoz 
való hozzáférést szabályozzuk, de komoly korlátai vannak, ha 
például az egyes üzleti folyamatokhoz szeretnénk hozzáféré- 
si jogokat rendelni. 

Az eddigi azonosítási modell kiegészítéseként a Windows 
2003 Server-ben mutatkozik be az Authorization Manager, 
amelynek segítségével lehetővé válik a funkcióalapú hozzáfé- 
résvezérlés. Az Authorization Manager biztosítja azt a keret- 
rendszert, amelynek segítségével a vállalat szervezeti modell- 
je megjelenhet az üzleti folyamatokat végrehajtó alkalmazá- 
sok biztonsági rendszerében. Az új API-k és felügyeleti eszkö- 
zök megkönnyítik az ilyen típusú alkalmazások fejlesztését, és 
a biztonsági rendszer megfelelő beállítását. 


A Windows NT 4.0 és a Windows 2000 felhasználó-azono- 
sítási modellje 

A Windows NT és a Windows 2000 objektumalapú azonosí- 
tási modellt valósít meg. Az erőforrás kezelő (resource 
manager, RM) felügyeli a gondjaira bízott objektumokat, a jo- 
gokat az objektum biztonsági leírója tartalmazza. Amikor az 
ügyfél hozzáférést kezdeményez a védett erőforráshoz, annak 
nevében az RM meghívja az AccessCheck API-t. Az 
AccessCheck API megvizsgálja az ügyfél biztonsági tokenjét, 
az igényelt hozzáférési módot, és az objektum biztonsági leí- 
róját. Ezután az AccessCheck API , igen", vagy ,nem" üzene- 
tet küld vissza az RM-nek, amely ennek alapján megadja, il- 


letve megtagadja az igényelt hozzáférést az objektumhoz. 
A hozzáférésvezérlés tehát objektumközpontú, a módszer egy- 
szerű, de a lehetőségek bizonyos szempontból behatároltak. 
Könnyen választ kaphatunk egy meghatározott objektum hoz- 
záférési jogaira vonatkozó kérdésekre, de komoly nehézségek- 
be ütközünk, ha például egy alkalmazáson belüli műveletek- 
hez szeretnénk jogosultságokat rendelni. 

Az objektumközpontú modell azt teszi szükségessé, hogy a 
rendszergazdák a vállalat szervezeti modelljét az objektumo- 
kon értelmezett jogosultságokra képezzék le, minden egyes 
objektum hozzáférésvezérlési listájába be kell kerülnie azok- 
nak a csoportoknak és felhasználóknak, akik valamilyen jogo- 
sultsággal rendelkeznek hozzájuk. 

Az alkalmazások fejlesztőinek számba kell venniük minden 
egyes objektumot, amelyekhez hozzáférésre van szükség az al- 
kalmazás egy adott funkciójának végrehajtásához, és meg kell 
adniuk a megfelelő felhatalmazást a felhasználóknak. További 
nehézséget jelent, hogy az objektumokhoz nagyon alacsony 
szinten kell jogosultságokat adnunk (például olvasási, vagy írá- 
si jog) ezek értelmezése egy magasabb absztrakciós szintről 
nem könnyű feladat. 

Minél inkább növekszik az objektumok száma és a hierarchia 
mélysége, annál több ponton kell a rendszergazdáknak egyedi 
módosításokat végezniük a biztonsági rendszerben. Az erőfor- 
rás és felhasználói csoportok rendszerének gondos megterve- 
zésével csökkenthető a probléma, de ennek fenntartásához egy 
nagyobb rendszer esetében igen következetes és koordinált 
rendszerfelügyeletre van szükség. A felhasználói csoportok ki- 
válóan alkalmasak az azonos jogokkal rendelkező felhasználók 
összekapcsolására, de komoly kihívás lehet a szervezeti folya- 
matok leképezése az objektumokhoz való hozzáférés szintjére. 


Funkcióalapú hozzáférésvezérlés 


A funkcióalapú hozzáférésvezérlés felhasználóközpontú azo- 
nosítási modellt valósít meg. A funkcióalapú hozzáférésvezér- 
lés segítségével lehetővé válik, hogy a jogosultságok hozzáren- 
delése a vállalat szervezeti struktúrájába illeszkedő módon va- 
lósulhasson meg. A modell központi objektuma a funkció, 
amelyhez hozzárendelhetjük azokat a felhasználókat, akik az 
adott munkafeladatot fogják ellátni, és amely közvetlenül tar- 
talmazza az erőforrások meghatározott csoportjára vonatkozó 
hozzáférési jogokat. 


A funkcióalapú hozzáférésvezérlés segítségével az engedélye- 
ket nem az objektumokhoz tartozó alacsony szintű jogok beál- 
lításával szabályozhatjuk, hanem lehetőség van az egyes mű- 
veletek és feladatok elvégzésének engedélyezésre, illetve tiltá- 
sára. A műveletek önálló egységként működnek, míg a felada- 
tok több műveletből (esetleg feladatból) állnak össze. Tekint- 
sünk példaként egy alkalmazást, amely lehetővé teszi, hogy 
felhasználói egy projekt állásáról jelentést tegyenek, közzéte- 
gyék az éppen aktuális állapotot, illetve megtekintsék az utol- 
jára közzétett adatokat. Az alkalmazás mindhárom feladathoz 
webes felületet nyújt. A jelentés leadásakor frissül az adatbázis, 
közzétételkor pedig a program e-mail üzenetet küld az érintett 
személyeknek. Az alábbi ábrán megfigyelhetjük, hogyan hasz- 
nálhatók fel az alacsonyabb szintű műveletek az egyes felada- 
tok összeállításához. 


Jelentés 
leadása 


Állapot 
megtekintése 


Állapot 
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E A feladatok alacsonyabb szintű műveletekből állnak 
össze 


A funkcióalapú hozzáférésvezérlési modell szerint a funkció 
jelenti azt az interfészt, amelyen keresztül a rendszergazda 
hozzáférhet a jogosultsági rendszerhez. Létrehozhatjuk pél- 
dául a ,Mérnök" funkciót, amely rendelkezik a mérnökök 
munkájához szükséges valamennyi jogosultsággal. A vállalat- 
nál dolgozó összes mérnököt hozzárendelhetjük a , Mérnök" 
funkcióhoz, így azok azonnal megkapnak minden szükséges 
jogosultságot. A funkciók segítségével a hozzáférést a vállalat 
szervezeti struktúrájának megfelelően szabályozhatjuk, a hoz- 
záférési rendszer kialakítása így egyszerűbb, és természetesebb 
módon történhet. 

Míg az ACL-ek kiválóan alkalmasak a jól meghatározott, állan- 
dó erőforrásokhoz való hozzáférés kezelésére, a funkcióalapú 
modell segítségével a munkafolyamatok, illetve az alkalmazá- 
sok által végrehajtandó műveletcsoportok (például olvasás 
adatbázisból, e-mail küldés) kezelhetők hatékonyan. 
Egészítsük ki az előbbi ábrát azokkal a funkciókkal, amelyek- 
nek jogosultságuk van az egyes feladatok elvégzésére. A , Mér- 
nök" funkció jogot kap a jelentések leadásához és a közzétett 
adatok megtekintéséhez, a , Vezető" közzéteheti és megtekint- 
heti az adatokat, az , Ügyintéző" pedig csak az adatok megje- 
lenítésére jogosult. 








Mérnök Vezető Ügyintéző 
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5 Funkcióalapú hozzáférésvezérlés 


A rendszer kialakításának legnehezebb pontja a funkció defi- 
azonban azt mutatja, hogy a funkció specifikációjának meg- 
változtatására csak nagyon ritkán van szükség, mindennapi 
feladatként csak a tagok hozzáadásával, illetve törlésével kell 
számolnunk. 


Azonosítás-tárolók (Authorization Stores) 


Az objektumalapú azonosítási rendszer a hozzáférési jogokat 
az objektumhoz csatolt ACL-ben tárolja. A funkcióalapú rend- 
szer esetében azonban a biztonsági információk az objektu- 
moktól különválasztva tárolódnak. Az Authorization Managert 
használó alkalmazás induláskor a biztonsági információkat eb- 
ből a tárolóból tölti be. A Windows Server 2003 Authorization 
Manager lehetővé teszi, hogy tárolóként az Active Directoryt 
vagy XML-fájlokat is használhassunk. 

Ha az Active Directoryt használjuk tárolóként, az Authoriza- 
tion Manager elkészíti a megfelelő objektumot magának a táro- 
lónak, és gyermekobjektumokat hoz létre valamennyi alkalma- 
záscsoport, alkalmazás, művelet, feladat és funkció számára. 
A tárolót tartalmazó XML-fájl csak NTFS fájlrendszeren tárol- 
ható (így ACL védi). Az XML-tároló fájl a hálózatban elérhető 
bármely számítógépen elhelyezkedhet. Hogy az objektumok 
átnevezésének lehetősége megmaradjon, az XML-fájl az egye- 
di azonosítókat (globally unigue identifiers, GUIDS) tartalmaz- 
za, így közvetlen szerkesztése nem ajánlható, és nem is támo- 
gatott. 

A tároló szerkesztésére az AzMan MMC konzol felhasználói 
felülete, illetve az Authorization Manager szkript nyelvekből 
(VBScript, Jscript) elérhető felülete szolgál. 


Az Authorization Managert használó alkalmazások 


A funkcióalapú hozzáférésvezérlés megvalósítása az alkalma- 
záson belül a következő lépésekből áll: 

A A fejlesztés közben meghatározzuk a funkciókat, imp- 
lementáljuk a műveleteket, és a műveletekből felépít- 
jük a feladatokat. 

A Telepítéskor a megfelelő API hívásokkal az alkalmazás 
létrehozza az azonosítás tárolót, a műveleteket és fela- 
datokat. 
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TA Futtatáskor az alkalmazás elindítja az Authorization 
Managert, hogy csatlakozhasson a tárolóhoz, és csato- 
lást hoz létre a tárolónak az alkalmazásra vonatkozó 
részéhez. 

TH Amikor ügyfél csatlakozik az alkalmazáshoz, az létre- 
hozza az ügyfél azonosítási kontextust. 

H Ezután már meghatározható az adott ügyfél funkciója, 
amelytől függően a felhasználói felületnek különféle 
részei töltődhetnek be, illetve bizonyos opciók elérhe- 
tővé, vagy rejtetté válhatnak. Minden művelet kezde- 
ményezésekor meghívódik az AccessCheck API, amely 
a felhasználó funkcióját figyelembe véve meghatároz- 
za, hogy az adott művelet végrehajtható-e. 


Csoportok az Authorization Managerben 


A Windows 2003 Server funkcióalapú hozzáférésvezérlési 
rendszere lehetővé teszi azt is, hogy a felhasználókat csopor- 
tokba szervezzük. A felhasználók úgy kaphatnak hozzáférést 
az alkalmazásokhoz, ha a domain felhasználói fiókjait, illetve 
csoportjait hozzárendeljük az alkalmazás által meghatározott 
logikai funkciókhoz. 
Ezen felül az Authorization Manager támogatja a csoportok 
szervezésének egy közbülső rétegét is. Alkalmazáscsoportokat 
(application group) hozhatunk létre, amelyek nyilvántartását 
az Azonosítás-tárolók (Authorization Store) végzik. A felhasz- 
nálókat az alkalmazáscsoporthoz, azt pedig a megfelelő funk- 
cióhoz rendelhetjük. Az Authorization Manager két különböző 
típusú alkalmazáscsoportot támogat: 
HA Hagyományos alkalmazáscsoport (Application Basic 
Group) 
H LDAP-lekérdezésen alapuló csoport (LDAP Ouery 
Group) 


Hagyományos alkalmazáscsoport 


A hagyományos alkalmazáscsoport a Windows NT csoportjai- 
hoz hasonló módon épül fel, azzal a különbséggel, hogy a ta- 
gok listája mellett tartalmaz még egy ,nem tagok" listát is. Ez a 
lista megkönnyíti a kivételek kezelését. A ,nem tagok" listáján 
szereplő felhasználók sem közvetlen, sem közvetett módon 
nem válhatnak a csoport tagjává (hasonlóan az ACL-ek enge- 
dély megtagadása lehetőségéhez). 


LDAP-lekérdezésen alapuló csoport 


A csoportokat gyakran úgy határozzuk meg, hogy a tagság az 
Active Directoryban nyilvántartott valamilyen tulajdonságtól 
(vagy tulajdonságoktól) függ. Például ha létrehozunk egy , Mér- 
nökök" csoportot, a tagok munkakörére vonatkozó adat való- 
színűleg az Active Directoryban is szerepel. Így azonban külön 
figyelmet igényel a csoporttagság és az Active Directory infor- 
mációk szinkronban tartása, mert természetesen a megfelelő 
tulajdonság beállításától az adott felhasználó nem válik a cso- 
port tagjává. 

Hogy hatékonyan felhasználhassuk az Active Directoryban tá- 
rolt információkat, és ne legyen szükség a többszörös admi- 
nisztrációra, az Authorization Manager lehetővé teszi LDAP- 
lekérdezésen alapuló csoportok létrehozásának lehetőségét. Az 
LDAP-lekérdezésen alapuló csoport tagságát az általunk meg- 
határozott LDAP-lekérdezés fogja összeállítani, mégpedig a 
hozzáférési kísérlettel egyidőben! Amikor a felhasználó hozzá- 
férést kezdeményez az adott funkcióhoz, az előre megadott 
LDAP-lekérdezés összeválogatja az Active Directoryból a cso- 





port tagjait, és ezután történik meg a csoporttagság ellenőrzése. 
Következzen néhány minta LDAP-lekérdezés, amelyet felhasz- 
nálhatunk a csoportok összeállításához: 


A felnőttek: 
HGESEZZTS ETT BHETTEMTT TÉT 





Minden magyar felhasználó: 


Minden magyar felnőtt: 


(kor5-18) (o: 





Dinamikus csoportok létrehozása az AzMan segítségével 


Az Authorization Managert használó alkalmazások felügyele- 
tére az Authorization Manager MMC (AzMan.mmc) használ- 
ható. A konzol segítségével a rendszergazda az alkalmazások 
funkcióihoz felhasználókat és csoportokat rendelhet, és alkal- 
mazáscsoportokat hozhat létre. Állítsuk össze a korábban em- 
lített mintaalkalmazásnak megfelelő alkalmazáscsoportokat az 
AzMan segítségével! 

A vállalatnál a munkaköröket az Active Directoryban tartják 
nyilván, például a mérnökök csoportját a következő LDAP- 
lekérdezés adja vissza: 





Az Authorization Manager lehetővé teszi azt, hogy a létreho- 
zott csoportok meghatározott alkalmazásra vonatkozzanak. A 
következő ábrákon nyomon követhetjük a hitelesítéstároló és 
az alkalmazáscsoportok létrehozását, valamint a funkciók és 
alkalmazáscsoportok összerendelését. 

Az Authorization Managert elindíthatjuk például a parancssor- 
ba beírt ,azman.msc" utasítással. Az első lépés az Azonosítás- 
tároló (Authorization Store) létrehozása (ezt általában az adott 
alkalmazás telepítője végzi, de most kézzel csináljuk). Hogy 
ezt megtehessük, az Authorization Managert Developer üzem- 
módba kell kapcsolnunk. (Action menü Options... parancs). 
Ezután a tároló létrehozásához válasszuk az Action menü New 
Authorization Store... parancsát. A tárolót most XML-fájlban 
helyezzük el, ennek útvonalát és nevét kell megadnunk. 


Select the authorization store type: 
C Active Directory 
Reguires Windows Server 2003 domain functional level. 
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GC XML file 
Store name: 


JEvelentesek. xmi Locations... I 


Description: 


HE 


[Eset [SS] 





DD Azonosítás-tároló létrehozása 


A tárolóban elhelyezzük az alkalmazást, a megfelelő művele- 
teket, feladatokat és funkciókat (általában ezt is az alkalmazás 
telepítője végzi) majd létrehozzuk a megfelelő (LDAP- 
lekérdezésen alapuló) alkalmazáscsoportokat (az alkalmazás 





alatti , Groups" sort kijelölve válasszuk az Action menü New 
Application Group... parancsát). 

Minden alkalmazáscsoportnak van neve (ez kötelező) és op- 
cionálisan leírást is csatolhatunk hozzá. A csoport típusát (ha- 
gyományos, vagy LDAP-lekérdezés) a létrehozáskor kell 
megadnunk, ez később már nem módosítható. 


New Application Group § 


Name: 


Mernokok 


Description: 


NNNNNNNNNENNNNN 
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Group type: 
C Basic 
6 LDAP guery 





E A csoport típusa: LDAP Ouery 


A csoport tulajdonságlapján megadhatjuk a tagokat összeválo- 
gató LDAP-lekérdezést. 


Mernokok Properties 


General. Guery ] 
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The LDAP guery that defines the members of this group: 


(munkazMernok) 





a A csoport tagjait a megadott LDAP-lekérdezés fogja 
összeválogatni 


Miután létrehoztuk az alkalmazáscsoportot, hozzá kell azt ren- 
delnünk az alkalmazás által létrehozott, megfelelő funkcióhoz. 
Mintaalkalmazásunkban szerepelt a , Vezető" funkció, akinek 
jogosultságot kell adnunk a jelentések közzétételéhez, és meg- 
tekintéséhez. A , Vezető" funkció mindenkori betöltőit a Veze- 
tők csoport tagsága fogja meghatározni. Rendeljük hozzá a 
, Vezetők" LDAP-lekérdezésen alapuló alkalmazáscsoportot a 
, Vezető" funkcióhoz. 





EZT zlölzi 
Idölzi 









Tnes T.esreten 
There sre na teme tö dor Nt vér 








nát 2 
kazap tggksten gané 


vot ZT La ez ESZE 
dsmj[9 6 ] Mecsowár.. ny voamerts [ 4 oestezore.... [4 reb and Su... [73 Authorizati (MI [52 szam 


E Funkció és alkalmazáscsoport összerendelése 


A megjelenő listából kiválaszthatjuk azokat az alkalmazáscso- 
portokat, amelyek az adott funkcióhoz fognak tartozni. 


Select the groups to add: 

[Name fwhereDefined ———— fDescipim 
CT A Memokok Application 
DD A Ugyirtezok Application 
I fi vezetok Application 
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a A "funkcióhoz tartozó alkalmazáscsoportok kiválasztása 


Az Authorization Store természetesen biztosítja az interfészt 
ahhoz is, hogy a fenti műveleteket programból végezzük el. 


Összefoglalás 


A Windows 2003 Server funkcióalapú hozzáférésvezérlési mo- 
dellje megkönnyíti az alkalmazások biztonsági rendszerének 
kifejlesztését. A modell a fejlesztők és a rendszergazdák szá- 
mára is segítséget nyújt, hogy a biztonsági rendszert a szerve- 
Zeti struktúrának és az üzleti folyamatoknak megfelelő módon 
alakíthassák ki. A hozzáférési információk tárolása az objektu- 
moktól függetlenül, azonosítás tárolókban (Autorization Store) 
történik, amelyek az Active Directory-ban és XML-fájlokban is 
elhelyezhetők. A rendszergazdák az alkalmazás által meghatá- 
rozott logikai funkciókhoz rendelhetik hozzá a felhasználókat 
és csoportokat. Az LDAP-lekérdezésen alapuló csoportok tag- 
sága futásidőben, az Active Directory-ban tárolt információk 
alapján alakul ki, így nincs szükség az adatok több helyen va- 
ló tárolására. 


. Szerényi László 
szerenyi.Iemet.hu 
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Elemszintű AD-visszaállítás? 
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Elemszintű AD-visszaállítás? 


Aelita ERDisk For Active Directory 


Az Aelita Software ERDisk For Active Directory terméke egy olyan eszköz a rendszeradminisztrátorok 
kezében, aminek használatával bátran állíthatjuk, hogy a címtár, illetve az azt hordozó szerverek 
működése bombabiztos. Minden, ami az AD mentéséhez és helyreállításához kell. 


A webes hirdetésekből már felületesen megismert rendszervé- 
delmi szoftvert vettem egy kicsit górcső alá. A sokat ígérő rek- 
lám után kíváncsi voltam, hogy valóban tudja-e azt, amit mon- 
danak róla. Kiderült, hogy annál még többet is. Az Active 
Directory, illetve annak felépítését meghatározó domain 
controllerek mentésére, visszaállítására szolgáló eszköz való- 
ban tudja azt, amire való, sőt a hálózatban található egyéb gé- 
pek — domain tagok — mentése is megoldható a segítségével. 
Természetesen ez nem egy fájlmentő rendszer, nem arra he- 
gyezték ki és nem is helyettesíti azok használatát. Ezen túlmu- 
tatva inkább a gépeket, felhasználókat, hálózati objektumokat 
magában foglaló címtár részletekbe menő ismeretével együtt 
egy olyan alkalmazás, aminek használatával nyugodtan alud- 
hatunk: az Active Directory biztonságban van! 


Telepítés 


Mivel fizetős termékről van szó, a tesztelést a demo verzió le- 
töltésével kezdtem. Ezt az [Aelita)] címről, regisztráció után te- 
hetjük meg. A tömörítve érkező állomány mérete is sokat sej- 
tet, hiszen 124 MB. Ezt kicsomagolva egy 160 MB-os CD-re 
való struktúrát kapunk, amit én gyorsan ki is karcoltam egy le- 
mezre. Ezt a CD-t használtam azután a direkt ezért készített 
Windows 2000 szerveren, ahol létrehoztam egy Active 
Directory tesztkörnyezetet. A W2k szerverről annyit kell tudni, 
hogy igyekeztem olyanná tenni, mint amilyenek a tipikus W2k 
kiszolgálók manapság: volt rajta IIS, Terminal Server, RAS, 
DNS, és mivel egyedül volt, övé volt az összes FSMO szerep 
is. Végül az SP3-at is feltettem rá, biztos ami biztos. A program 
az ismertetők szerint a .NET szervercsaláddal is használható! 
Mivel a CD-n a fájlok között van egy autorun.inf is, szépen el 
is indult mikor beraktam a meghajtóba. Itt rögtön egy igényes 
kezdőkép fogad, ahol kiválaszthatjuk a telepítést, illetve a rész- 
letes dokumentációt PDF formátumban, ezenkívül egy flash-es 
demo és HTML ismertető is része a csomagnak. Ezt érdemes 
megnézni, itt tudjuk meg ugyanis, hogy mi van a kezünkben, 
mire is való a termék. Miután végigkattintgattam az ismertető- 
ket, elindítottam a tényleges telepítést. Az Install menüpont 
rögtön tartogat is egy kis meglepetést, mert a tényleges termék 
mellett még találunk itt hozzá való Reporting Console-t, illetve 
az SOL Server 2000 Desktop Engine (MSDE) is telepíthető in- 
nen. Erre a log-ok illetve a reportok készítésénél lesz majd 
szükség. (Használhatunk persze egy már meglévő, futó SOL 
szervert is, ha van.) 

A szoftver működésének egyébként nem feltétele az SOL, e 
nélkül is működik az alap backup/restore. Ha a Reporting 
Console használatát is tervezzük a jövőben, az még igényli az 
MDAC (Microsoft Data Access Components) minimum 2.6-os 


A program használata 


A telepítést célszerű az egyik — ha van több -— domain 
controller gépen elvégezni, mert ott , biztos" hozzáférés van az 
Active Directoryhoz és a domainhez. Jó megoldás az is, hogy- 
ha kinevezünk egy backup gépet a hálózaton, aminek megfe- 
lelő védelme és tárkapacitása van, amire azután a DC-ken fu- 
tó ERDisk agent-ek küldik az adatokat. 


Active Directory Recovery 





Hl EZ Complete OHline Restorc 
si or 


— e la 
Active Directory 7 HEJ 
Se Granular Online Restore 


e—s Domain 
Controller 
Central 
Storage Location 
Domain 477 
Controllers 
AD Backups 


2 Központosított mentés és visszaállítás 


A választást a rendelkezésre álló lehetőségek, illetve a hálózat 
és a domain mérete is befolyásolja. A program kezelőfelülete 
egy kiforrott, kényelmes MMC modul, aminek használata köz- 
ben végig megmarad az az érzésünk, hogy valóban hozzáér- 
tő (a Microsoft rendszerét behatóan ismerő) szakemberek által 
készített eszköz van előttünk. A program által generált .bkf fáj- 
lokat érdemes biztonságos — minimum RAID1 - helyre tenni 
és más mentési megoldással is védeni őket az esetleges el- 
vesztéstől, sérüléstől. Vegyük észre, hogy a fájlok kiterjesztése 
a Windows által használt szabványos mentési struktúrára utal, 
így a ,sima" beépített NT-backup is , érti" az így készült vége- 
redményt. Amit pluszban kapunk, az a részletes, naplózott 
mentés és a legfontosabb: a differenciált restore! Ez azon ala- 
pul, hogy a visszaállítani kívánt mentést a rendszer előzőleg 
összeveti az aktuális állapottal és felkínálja a választást, hogy 
mit mivel, mikori dátummal állítsunk vissza. Ez a módszer 
nagyon biztonságos, mert amúgy könnyen lehetne nagyobb 
bajt csinálni egy aktualitását vesztett mentéssel. Próbálkozá- 
saim során szándékosan tettem olyasmit is, ami szokványos 
esetben nem fordul elő a mindennapos üzemeltetéskor. 
Készakarva tönkretettem pár container-t, group policyt illetve 
kitöröltem létfontosságú felhasználói fiókokat, csoportokat és 
jogosultságokat állítottam el. Mindez nem okozott nagyobb 
problémát, a rendszer jól vette az akadályokat. 





ERDisk Repair Wizard 


Computer and Backup Selection 
You can testore selected components on a computer Írom any System State 
backup that ís available for that computer. 





Locate backup under computer name and select components to be restored: 
a H W2KSRV 
A TT (a 5/8/2003 11:47-18 AM (Age: 0 days) 
a TT ég Active Directory 
T 2 DIT Database 
TT 84 SYSVOL 







B TT gp Registy 
ff a COM: Class Registration Database 
TT tudh Boot Files 
TT tudh System Piotected Files 
Tf IS Metabase z 






To catalog a backup file. click Register Backup. 








A Részletesen válogathatunk a backup során 


A mentés és visszaállítás alatt részletekbe menően válogatha- 
tunk, hogy mire van szükségünk. A program ezen része is 
könnyen átlátható, kezelhető. Egy teljes backup a tesztszer- 
verről egy 104 MB-os fájlt eredményezett, de ebben benne 
van a beépített backup részeként már megismert System State 
is. Természetesen a végső fájl mérete nagyban függ az adott 
gép, illetve az Active Directory bonyolultsági fokától. Nagyon 
kényelmes az a megoldás is, ahogyan a program a mentések 
neveit generálja, megkönnyítve ezzel a későbbi adatkeresést. 
Képes ugyanis a dátumból, rendszeridőből, gépnévből össze- 
állítani a mentés nevét, ami nagyon sokat segít, amikor tény- 
leg baj van. 

A tervezők gondoltak arra az esetre is, amikor akkora a prob- 
léma, hogy esetleg el sem indul a gép. Erre találunk egy Boot 
Disk Wizard nevű menüpontot, ahol elkészíthetjük a gép in- 
dításához, illetve a parancssori Recovery Console eléréséhez 
szükséges indítólemezeket. 


Itt ért egy nagyon kellemes meglepetés, ugyanis a program ké- 
pes az indítókészletet ISO CD image formátumban is előállí- 
tani, ami jóval gyorsabb és kényelmesebb, mint a floppyleme- 
zes megoldás. A visszaállítás is lehet online, vagy — Directory 
Services Restore módban indított szerver esetében — offline. 
Mindkettőt kipróbáltam és a végeredmény az lett, hogy a 
tesztszerver még mindig tökéletesen működik. Pedig nagyon 
sokat kapott szegény... Ilyen hibahalmaz — amiket okoztam — 
egyszerre, egy szerveren csak nagyon ritkán fordul elő a gya- 
korlatban, úgyhogy mindenképp a szoftver megvásárlása mel- 
lett teszem le a voksom. Az ERDisk for AD használatával min- 
den rendszergazda nyugodtabb lehet, a rendszer védelme így 
sokkal közelebb kerül a hőn áhított — a valóságban sajnos még 
elérhetetlen — tökéleteshez. 


Jelentések készítése 


A rendszer kézbentartásának egyik alapfeltétele a változások, 
hibaesemények, visszaállítások részletes naplózása. Ennek 
meglétével az esetleges gyenge pont keresés is könnyebbé vá- 





lik, illetve fény derülhet egy-egy tömítetlen biztonsá- E] 
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gi résre is. A jelentéskészítő verziószáma a demo ese- 
tében 5.2-es volt, így valószínűsíthető, hogy lesz még 
fejlesztés. A próbák során nagyon részletes, színes- 
szagos reportokat kaptam, amik valóban jók voltak. 
Az eredmény vetekszik a Seagate Crystal Reports-szal készíthe- 
tőkkel. 


Automatizálás, ,,set it and forget it" 


Mivel lehetőség van a kiválasztott hálózati objektumok időzí- 
tett mentésének beállítására is, jól átgondolt backup stratégia 
megtervezésével teljesen automatikussá tehetjük a védelmet. 


Schedule ] 


h. 4t 8:00 PM on the first Mon of every month, st; 5412/2003 r] 
New Delete I 


Schedule Task: Start time: 
[Monthly r] [ 8:00 PM aa Advanced... I 
7 Schedule Task Monthly 


C Day [/ 3 ofthe monthíg) 
CG The [first y [Monday r] ofthe monthís) 


Select Months 








[7 Show multiple schedules. 





2 Az időzítéssel automatizált mentés 


Nagyon jó ez, amikor hosszú hónapokig üzemzavar-mentes 
időszak után egyszer csak beüt a systemcrash és van mihez 
nyúlni, gyorsan, hatékonyan tudjuk elhárítani a problémát. A 
program demoja egy kedves marketingfogással próbálja meg a 
tesztelőit még jobban megnyerni. A letöltési regisztráció alatt 
ugyanis felajánlja, hogy amennyiben bármilyen rendszeren si- 
keres visszaállítást hajtunk végre, a restore-t követő ablakban 
megadott regisztrációs adatok szerint egy céglogóval ellátott 
pólót kapunk ajándékba. Ha meg is érkezik a ,nyeremény", 
nem ezért fogom a jövőben használni a programot, hanem 
mert a tesztelés során számomra kiderült, hogy valóban haté- 
kony eszközről van szó, amivel nagyságrendekkel biztosabbá 
tehető az AD mentése, védelme. Ám ha valakinek még ez sem 
elég, akkor nézelődjön egy kicsit az [aelprod] címen, ahol a 
cég többi — a windows alapú rendszerekhez készített — admi- 
nisztrációs termékével is megismerkedhet. 


Füzesi Szabolcs 
fuzesiszOgosi.hu 
MCSA 
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A DALP rejtett szépségei 7 Il. 


A Windows-rendszerekben működő DHCP-kiszolgáló telepítése több, egymástól 
független lépésből áll. A hitelesítés buktatóinak ismertetése és az első címtarto- 


mány létrehozása után azt vizsgáljuk, milyen integrációt lehet megvalósítani a 
címkiosztó és a névfeloldó szolgáltatások között. 


A DHCP-kiszolgáló telepítése magától értetődő: a funkciót a 
Windows-komponensek hálózati szolgáltatásai között találjuk. 
A telepítéssel azonban még nem kapunk azonnal üzemkész 
eszközt. Ha tartományi környezetben, Active Directoryval dol- 
gozunk, el kell végeznünk egy ún. hitelesítési eljárást, és — kör- 
nyezettől függően — be kell állítanunk, hogy milyen adatokat 
szeretnénk az ügyfelek felé közvetíteni. 


A DHCP hitelesítése 


A hitelesítés biztonsági okokból szükséges. Ha bárki telepíthet 
DHCP-kiszolgálót, és azt konfigurálja, könnyen előfordulhat 
(és a funkció megléte azt mutatja, elő is fordult), hogy helyte- 
len paramétereket kapnak, majd furcsa, nehezen megfejthető 
tüneteket produkálnak a munkaállomások. Előfordul, hogy 
nem képesek a helyi hálózaton túli gépekkel kommunikálni 
(rossz az alapértelmezett átjáró paraméter), vagy már a címet is 
rossz tartományból veszik (nem megfelelő a scope). A gondo- 
kat megelőzendő a DHCP ellenőrzi, hogy az Active Directory 
számon tartja-e a neki helyet adó kiszolgálót a hitelesített 
DHCP-szerverek listáján. Ha a megfelelő bejegyzés hiányzik, 
a szolgáltatás leáll, és az eseménynaplóban elhelyez egy rövid 
magyarázatot tartalmazó hibaüzenetet. 

A hitelesítést a DHCP-konzol segítségével végezhetjük el, ha 
tagjai vagyunk a gyökértartomány , Enterprise Administrators" 
csoportjának. Ez egy meglehetősen fontos momentum. A kü- 
lönböző magyarországi Windows 2000 előadásokon azt hall- 
hattuk, hogy a mi üzleti életünkben elegendő egyetlen tarto- 
mányrt létrehozni. A kétségtelen előnyök (egyszerűség, átlátha- 
tóság, bizonyos bonyolult szituációk elkerülése) mellett azon- 
ban ez a szerkezet hátrányos is lehet. Egyetlen tartományban, 
amely egyben a gyökértartomány is, a , Domain Administra- 
tors" csoport tagjai bármit megtehetnek. Ha el is vesznek tőlük 
jogokat, azokat képesek visszaszerezni, még a ,restricted 
groups" csoportházirend-trükk sem akadályozhatja őket. 

A problémát úgy lehet megoldani, ha az AD tervezésekor a 
gyökértartományt egy üres domainnek tervezzük, és alatta 
építjük ki a , valódi" adminisztrációs egységünket. A gyökér ad- 
minisztrátorainak (számbeli) korlátozásával már könnyedén 
elérhetjük a célunkat, nevezetesen, hogy ne végezhessen el 
akármilyen műveletet egy rendszergazda, csak ha erre külön 
engedélyt kapott. (Technikai értelemben a hitelesítés egyetlen 
feltétele, hogy az AD NetServices konténeréhez teljes hozzáfé- 
rési joggal rendelkezzen a felhasználó.) 


A fenti séma a DHCP szerverek esetén nagyon erős kontrollt je- 
lent. Több száz telephely meglétekor is legfeljebb 2-3 hozzáér- 
tő kezében összpontosul a címkiosztó szolgáltatás engedélye- 
zése. (Továbbá a RIS szervereké is, ahogy ez majd később lát- 
ható.) Ezzel együtt a hitelesítés eljárása delegálható az AD de- 
legációs mechanizmusán keresztül. 


És van élet az AD-n kívül? Igen van: Novell, Linux, sőt NT4-es 
DHCP-kiszolgálók nem veszik figyelembe a Windows 2000 
címtár korlátozását, tehát az igazán rosszakaró kárt tehet — a 
kontárkodástól és figyelmetlen üzemeltetőktől azonban az AD 
megvéd. 

Azt az eljárást, amely a hitelesítés meglétét ellenőrzi a Win- 
dows 2000 és 2003 szerverek ,rouge detection" műveletnek 
nevezik. A kiszolgálók, amelyek az ellenőrzést végzik, eltérő 
módon viselkednek attól függően, hogy tagjai-e egy Active 
Directory tartománynak, vagy sem. Ha AD-tagok (tagkiszolgá- 
lók, vagy tartományvezérlők), egy LDAP-lekérdezést kezde- 
ményeznek, hogy megállapítsák, tagjai-e a hitelesített kiszol- 
gálók listájának. Igenlő válasz esetén tovább működnek, 
egyébként leállnak. 

Ha a Windows 2000 kiszolgáló nem tagja AD-tartománynak, 
hanem úgynevezett stand-alone, vagyis munkacsoport üzem- 
módban fut, vagy egy NT4 tartomány tagja, a DHCP-szerver 
indulásakor egy DHCP-INFORM szórt üzenetet helyez el a 
hálózaton. Ez az üzenettípus számos gyártóspecifikust opciót 
tartalmaz. A csomaggal a kiszolgáló más DHCP-szervereket 
keres, amelyek egy AD gyökértartományában helyezkednek 
el. A kért opciók alapján a megcélzott DHCP-szerverek infor- 
mációkat küldenek vissza a gyökértartományról. A válasz 
DHCPACK csomagban érkezik. Ezzel a módszerrel egy (de 
akár több) gyökértartományról is tudomást szerezhet az épp 
induló DHCP-szolgáltatás. Ha nincs AD a helyi hálózaton, a 
szolgáltatás elindul, de minden ötödik percben DHCP- 
INFORM csomagot bocsát ki, tovább kutatva a Windows 
2000 címtára után. j 

Ha már az első csomagra is érkezett válasz, minden egyes fel- 
fedezett gyökértartomány felé egy lekérdezést indít a DHCP- 
kiszolgáló, hogy ellenőrizze, tagja-e a hitelesített szerverek 
csoportjának. Amennyiben egyik listán sem találja magát, a 
szolgáltatás leáll. Ez azt jelenti, hogy nem kell feltétlenül egy 
Windows 2000 szervernek tartománytagnak lennie, hogy ér- 
vényes legyen rá a hitelesített szerverek listája! 


Szerverkonfiguráció 


Miután szerencsésen átestünk a hitelesítési eljáráson, igazán 
nekieshetünk az érdemi konfigurációnak. 

Az első feladat a megfelelő scope (bérlettartomány) létrehozá- 
sa. Ezt egy varázsló segíti: meg kell adnunk a kezdő- és a vég- 
ső címet, amelyet a scope-on belül a szolgáltatás kioszthat, az 
alhálózati maszkot, a bérletidőt és a kivételeket, vagyis azokat 
a címeket a tartományon belül, amelyeket mégsem lehet kiosz- 
tani. Miután végeztünk, megjelenik egy scope a konzol bal ol- 
dalán. A következő ábra az általános tulajdonságokat mutatja. 
A legproblémásabb kérdés a bérletidő meghatározása. A rend- 
szer hét napot ajánl fel és általában ezt el is fogadhatjuk. Szá- 
mos megfontolás azonban amellett szól, hogy gondoljuk át 


alaposan ezt az értéket. Elméletileg a hosszabb bérletidő azt je- 
lenti, hogy a gépek kevesebbet kommunikálnak a kiszolgáló- 
val, vagyis nem terhelik azt. Hétnapos bérletidő esetén három 
és félnaponta küldenek bérletmegújítási kérelmet, míg például 
28 napos bérlet esetén csak tizennégy naponta - látszólag ez 
tiszta haszon. 
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Scope [10.0.0.0] MAL-W2000 tulajdonságai 


General ] DNS (/ Advancedi 
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StartiP address: (10. 0.1.1 


Scope name: 


EndíP address: [ 10. 0. 5 .254 
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Lease duration for DHCP clients 
(6 Limited to: 

Days: Hours: Minutes: 
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C Unlimited 


B MAL Székesfehérvári telephelyének DHCP b 


B A scope legfontosabb adatai 


Description: 














Csakhogy a megtakarítás egyedül a soha ki nem kapcsolt gé- 
pekre vonatkozik, mert az induló DHCP ügyfelek mindenképp 
kérnek címet a szervertől. A nyereség tehát csekély. Ezen még 
az sem segít, ha végtelenre állítanánk a bérletidőt — sőt azzal 
csak rosszabbul járunk. A bérletidő végtelenre állítása azt je- 
lenti ugyanis, hogy a bérletidőnek nincs fele, tehát nem kell 
kérni a meghosszabbítását sem. A végtelen időre kiadott cím 
elvész, nem használható újra. Ezért azt javaslom, hogy sohase 
adjunk meg végtelen hosszú bérletet! A túl rövid idő sem jó, 
mivel sok ügyfél esetén ez a reggeli csúcs mellett is valóban 
nagy forgalomhoz vezet. 

A legcélszerűbb megbecsülni az ügyfelek és a kiosztható cí- 
mek arányát. Ha sok ügyfélre jut relatíve kevés cím, célszerű 
rövid bérletet megadni (pl. 3 nap). Ha sok címünk van és ke- 
vés ügyfelünk, a címkiosztás szólhat akár 15 vagy 30 napra is. 
A címtartomány kijelölésével és létrehozásával azonban még 
korántsem kapunk működő szolgáltatást. Egy Windowsos kör- 
nyezetben meg kell adnunk néhány nagyon fontos opciót 
(konfigurációs paramétert) is, amely az ügyfeleket eligazítja. A 
következő ábra egy ilyen listát mutat be. 
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E Az öt kritikus opció Windows környezetben 
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Mindenekelőtt tudatni kell az ügyfelekkel az ÁL] 


Mori 


alapértelmezett átjáró címét — az opció száma 003, 
és magyarul az , útválasztó" nevet kapta a keresztség- 
ben, ami esetleg kissé félrevezetheti a kezdő rend- 
szergazdákat. 

Windows 2000 környezetben kritikus, egyébként is mind fon- 
tosabb a DNS kiszolgálók adatainak pontos beállítása. A 006 
opció teszi lehetővé akár több kiszolgáló megadását is. A fon- 
tosságot a sorrend jelzi. 

A tartományi ügyfelek számára meg kell adni, hogy a 
hostnevükhöz milyen DNS suffix-et, vagyis tartományi kiegé- 
szítést biggyesszenek. Ha a gép hostneve mal-001 , mostantól 
az ügyfél tisztában lesz a teljes nevével: mal-001 .mal.priv. 
(Egy különös hibával találkoztam nem is olyan régen. A jelen- 
ség az volt, hogy a kliensünk mindenáron a proxy szerverün- 
ket akarta használni egy belső weblap eléréséhez is, holott 
nem ez volt a kívánatos. Kiderült, hogy egy elővigyázatlan 
kollégánk egy hibás DNS suffixet adott meg — kézzel — ami fe- 
lülírta a DHCP beállításokat. A , Helyi intranet címek esetén a 
proxy figyelmen kívül hagyása" beállítás ezért nem működött. 
A paraméter törlése és egy újraindítás segített. Tanulság: sem- 
mit se konfiguráljunk az ügyfélgépeken az IP beállítások kö- 
zött!) 

A DNS kiszolgálók mellett természetesen meg kell adni a 
WINS szerverek címét a 044-es opcióban. Végezetül a 046-os 
paraméterre is szükség van, ezzel definiáljuk, hogy a NetBIOS 
szabványt használó ügyfelek milyen stratégiát folytassanak a 
névfeloldáshoz. A legelterjedtebb a hibrid-node üzemmód, 
ennek a kódja a 0x8. A leírásunk keretein túlmutat a NetBIOS 
névfeloldási stratégiák ismertetése, de egy korábbi technet 
cikkben ez fellelhető, esetleg a 0119493-as cikk tisztázza az 
idetartozó NetBIOS fogalmakat. 

(Ha ragaszkodunk a technikai részletekhez, el kell monda- 
nunk, hogy tulajdonképpen szinte minden adat DHCP- 
opcióként jut el az ügyfelekhez, még akkor is, ha a kezelői fe- 
lületen máshol állítottuk is be. Az alhálózati maszk a 001-es, 
a bérlethossz a 051-es, a megújítási idő a 058-as, ez 
alapértelmezetten 5096, és a címkérési idő, 059-es, amely ál- 
talában 87.596. A Windows-ügyfelek a fenti opciókon kívül 
mást nem vesznek figyelembe.) 


A DNS és a DHCP együttműködése 


A scope tulajdonságai közé tartozik a DNS-sel való együttmű- 
ködés definiálása is. Windows 2000 és AD környezetben ez 
nagyon fontos paramétercsoport. Lássuk részletesen, miről 
van szó. 
Engedélyezhetjük, vagy tilthatjuk, hogy a DHCP-kiszolgáló au- 
tomatikusan frissítse az ügyfelei DNS zónarekordjait. 
Amennyiben engedélyezzük a frissítést, választhatunk, hogy 
csak az ügyfél kérésére történjen a regisztráció, vagy minden- 
képp végezze el a DHCP-szolgáltatás. Hogyan működik 
mindez? 
A Windows 2000 és Windows XP a saját DHCPREOUEST cso- 
magjában használ egy 81-es opciós számmal rendelkező, Fully 
Oyalified Domain Name nevű mezőcsoportot, amelyben meg- 
határozza, hogy a DHCP-kiszolgáló miképp regisztrálja a meg- 
felelő rekordokat a DNS adatbázisban. Számunkra a mezőcso- 
port harmadik tagja érdekes, amely a következő értékeket ve- 
heti fel: 

0 - az ügyfél regisztrálja a saját hostrekordját. 

1 - az ügyfél azt szeretné, hogy a DHCP-szerver regisztrál- 

ja a hostrekordot 
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3 —- a DHCP szerver frissíti a hostrekordot az ügyfél beállí- 
tásától függetlenül. 





mal-corpserv1 .mal. priv [10.0.0.24] tulajdonságai 


General DNS ] Advanced] 


You can setup the DHCP server to automatically update authoritative DNS 
servers with the host (6) and pointer (PTR) records of DHCP clients. 


[7 Enable DNS dynamic updates according to the settings below: 


(7 Dynamically update DNS 4. and PTR records only if reguested by 
the DHCP clients 


€ áAlviays dynamically update DNS A and PTR records 


[7 Discard A and PTR records when lease is deleted 


(7 Dynamically update DNS A and PTR records for DHCP clients that do 
not reguest updates (for example, clients running Windows NT 4.0) 











Mégse Alkalmaz 


5 A DHEP és a DNS szolgáltatások együttműködnek, ha 
ez mi beállítjuk 





Az értékek között nem található olyan, amely a PTR rekordok- 
ra vonatkozna. Azt minden esetben a DHCP-kiszolgáló jegyez- 
teti be, kivéve, ha a DHCP-szerver nem ismeri a 81-es opciót. 
A Windows 2000 és XP kliensek ezt felismerik, és ők végzik re- 
kordírissítést a DNS-szolgáltatás megfelelő reverse lookup zó- 
nájában. 
A opció értékének beállítását a TCP/IP konfigurációs paneljé- 
ben lehet elvégezni, még ha ez elsőre nem is tűnik fel. 
Speciális TCP/IP. beállítások 
IP-beállítások DNS — WINS Beállítások 


DNS-kiszolgálók címei, használati sorrendben: 





Hozzá 


A következő három beállítás lesz alkalmazva minden olyan kapcsolatnál, 
ahol a TCP/IP engedélyezve van. A nem minősített nevek esetén 


0 Elsődleges és kapcsolatfüggő DNS -utótagok hozzáfűzése 
(JJ 4z elsődleges DNS-utótag szülőutótagjainak hozzáfűzése 
0 4 következő DNS-utótagok hozzáfűzése (ilyen sorrendben]: 





A kapcsolat DNS -utótagja: 


zíI A kapcsolat címének regisztrálása a DNS-be j 
4 kapcsolat DN5-utótagjának használata DNS regisztrációhoz 


B A, titokzatos" 81-es opció a kezelőfelületen 

















A bekarikázott jelölőnégyzet bekapcsolt állapotban gondosko- 
dik arról, hogy az ügyfél a DHCP-Reguest csomagban a 81-es 
opcióban 1-es értéket küldjön a szervernek. 
Vajon mikor érdemes az ügyfélre és mikor a kiszolgálóra bíz- 
ni a rekordírissítést? Nos, általában mindegy, hogy a feladatot 
ki végzi el. Ha azonban olyan DHCP-ügyfelünk is van, amely 
több hálózati kártyával is rendelkezik (multihomed), a klien- 
sekre kell hagyni a regisztrációt — épp úgy, ahogy a korábbi 
ábrán láthattuk. A DHCP-szolgáltatás ugyanis egy ügyfélhez 
csak egyetlen ,A rekordot" jegyez be, illetve felülír minden 
korábbi bejegyzést, ami a többlábú gépeknél nem előnyös. 
Szintén nem ajánlott a DHCP-kiszolgálókra bízni a DNS-re- 
kordírissítést, ha a DNS csak biztonságos rekordífrissítést vár el 
(secure update). Ebben a szituációban a bejegyzésnek a 
DHCP-szolgáltatás válna a tulajdonosává, ami gondot jelent- 
het. Ha például egy NT4-es ügyfél DNS rekordjának bejegy- 
zését a DHCP-szerver végzi el, majd a gépet fírissítjük Win- 
dows 2000-re, az új rendszer nem lesz képes a saját rekordjá- 
nak a kezelésére, mert nem ő a tulajdonosa. Hasonló helyzet 
alakulna ki, ha két (egymásnak tartalék) DHCP kiszolgáló kö- 
zül az egyik meghibásodik. Ugyanazt a hostcímet a tartalék 
DHCP-szerver nem fírissítheti, mert nem tulajdonosa. Summa 
summárum: biztonsági frissítéskor ajánlatos megfontoltan 
használni a DHCP és a DNS ilyen irányú integrációját. 
És mi történik, ha az ügyfél nem is ismeri a 81-es opciót? Ilyen 
kliensek a Windows NT4, Win95, Win98. Számukra is képes 
a regisztráció elvégzésére a DHCP, ha a zóna tulajdonságai 
között az utolsó jelölőnégyzetet bekapcsoljuk. 
Végezetül adódik a kérdés: miért van szükség a DHCP-n ke- 
resztüli dinamikus írissítésre? Miért kell a dinamikusan válto- 
zó ügyfelek címét regisztrálni? Egyszerű: korábban a Microsoft 
ügyfeleket szórt csomagokkal, később a dinamikus regisztrá- 
ciót lehetővé tévő WINS névfeloldó szerverek segítségével le- 
hetett megtalálni. Ha egy munkaállomáson működik egy 
megosztott nyomtató, arról a szolgáltatásról a WINS-adatbázis 
tartalmazott egy bejegyzést, a browser szolgáltatás egy erőfor- 
ráslistában tárolta, s egy WINS-hez címzett névfeloldási kére- 
lem után könnyedén fel lehetett venni a kapcsolatot azzal a 
bizonyos munkaállomással. A NetBIOS-szabványok eliminá- 
lásával azonban a fenti mechanizmusból semmi sem marad: 
nincs broadcast, sem WINS, sem browser szolgáltatás. Van vi- 
szont Active Directory az erőforrás nyilvántartására, LDAP- 
lekérdezés a meglétének ellenőrzésére, dinamikus képessé- 
gekkel felvértezett DNS a névfeloldáshoz — sőt az új kliensek 
esetén még dinamikusan frissített DNS-bejegyzések is. A ré- 
gebbi operációs rendszerek viszont mit sem tudnak az új idők 
új szeleiről, s ők bizony nem képesek a DNS-bejegyzés írissí- 
tésére. Ha azonban valami ezt elvégzi helyettük, a korábbi 
NetBIOS-funkcionalitás minden vonatkozásban megmarad, 
csak új szabványokkal. Egyszer talán alaposan végig kellene 
gondolni, hogy a különböző NetBIOS-funkciókat és szolgálta- 
tások mi módon cserélte fel a Microsoft natúr TCP/IP megol- 
dásokkal — szigorúan ragaszkodva a meglévő RFC-khez. De 
ez már egy másik történet. 
Lepenye Tamás 
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Network 4 Management -- Tools. Nyilvánvaló, hogy az ide tartozó eszközök fontosságát nem kell 
hosszú lére eresztve indokolni. Network mindenhol van, a Management a rendszergazda munkájának 
jelentősen kidomborodó része, úgyhogy nézzük sebesen a harmadik összetevőt. 


A bevezetésnek megfelelően ebben a részben olyan eszközök 
után turkálunk, amelyekkel - általában a saját jól felfogott ér- 
dekünkben -— hálózatunk, felhasználóink és alkalmazásaink 
adminisztrációjával kapcsolatos teendőinket oldhatjuk meg, 
idevágó problémáinkat zárhatjuk rövidre. Mindezt általában 
parancssorból (lehetőleg távolból is), mert az ma újra trendi O. 
Persze, komolyabban szólva, inkább az ,erőforrásigénytelen- 
sége", univerzális mivolta és programozhatósága miatt kívána- 
tos sokak szemében. A Windows 2000 Resource Kit Network 
Management Tools csoportjában bőven kiélhetjük ilyen irányú 
vágyainkat. 


Addusers.exe 


Egészen egyszerű mulatság ezzel a programocskával egy szö- 
vegállományból (amit pl. fáradságos munkával egy általunk 
betanított gépírónő segítségével készített Excel táblázatból 
is legyárthatunk) felhasználókat/csoportokat faragni! Pár 
dologra kell csak figyelnünk: pl. arra, hogy a szükséges szö- 
vegállományban a Windows .ini formátumát kell kövessük, 
valahogy így (persze a legfelsőt például egy sorban, de itt nem 
fér el): 

[User] 


User Name, Full name, Password, Description, 
4 HomeDrive, Homepath, Profile, Script 


[Global] E k 5 
Global Group Name, Comment, UserNamel, UserN 





[Do0cal] vi d 
Local Group Name, Comment, UserNamel, UserName2 ... 


Látható a példa alapján, hogy a legfelső szekcióban a felhasz- 
nálóval, alatta a globális, legalul pedig a lokális csoportokkal 
kapcsolatos kreativitásunkat tesztelhetjük le. Továbbá nem mu- 
száj minden egyes azonosítót beírni (nem biztos, hogy minden 
usernek kell mondjuk Description), mert egy vesszővel (vagy a 
/s:x kombinációval, ahol az x egy bármilyen, sőt esetleg már 
adott elválasztó karakter) egyszerűen helyettesíthetők. Ellen- 
ben a szóközzel csínján bánjunk a vesszők előtt és mögött, 
mert csinos hibaüzenetek várhatók pl. a csoportba helyezés- 
nél, mivel a , User" nem ugyanaz mint a , User"! A Script pe- 
dig ebben az esetben a login szkriptet jelöli. Ha tehát megvan 
a szabályosan elkészített szövegfájl, akkor a 

jaddusers /e üsers.€xt Ez d 
paranccsal indíthatjuk is. Ha viszont meg akarunk ismerkedni 
a parancs további kapcsolóival, újabb finomságokkal futunk 





össze, pl. a /p argumentumai a jelszóval kapcsolatos jogokat 
szabályozzák: 
A I: a felhasználó nem változtathatja meg a jelszavát a 
következő belépéskor 
A c: a felhasználó egyáltalán nem változtathatja meg a 
jelszavát 
A e: a jelszó soha nem jár le (ez automatikusan az elsőt 
is okozza) 
TA d: a fiók letiltott lesz. 


További élvezetet jelenthet a /d kapcsoló, mert ezzel és a lét- 
rehozandó állomány nevének kombinációjával egy ,dumpot", 
magyarul a jelenlegi felhasználó/csoport listát kaphatjuk meg. 
Ezt azért is érdemes első körben megtenni, hogy vethessünk 
egy hosszabb pillantást a létrehozásnál majd szükséges struk- 
túrára. A következő paranccsal a törlést is elvégezhetjük: 


addusers /e okmarnemdolgoznakitt.txt 


Ezzel csak óvatosan, mert ugye azt tudjuk, hogy ha egyszer 
letörlünk egy felhasználói fiókot, ugyan pl. a fiók neve válto- 
zatlan formában újra legenerálható, de a lényeg, a SID-je 
(Security IDentifier), amely a jogosultsági listákban szerepel, 
már örökre a múlté. Meg aztán ha egy bármilyen típusú cso- 
port szerepel ebben az állományban, az eszköz nemcsak a 
usereket szedi ki a csoportból, hanem végleg ledönti lábáról a 
csoportot is. 


[LAST Sza zh Ta 


Program File 
CG 


TT: 

" created 

EGET ÉLT 

sg! É added to grou; 

1 z KEPEIT 

li 8 ided to group 
u. FEEL KT át Tett Tá 


Tsi s 
Global group " 
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Program FilesXResource Kitd. 


Kész az IT csoport 


Van még egy szimpatikus dolog ebben az eszközben: mint ál- 
talában az összes Resource Kit parancssori eszközt, ezt is hasz- 
nálhatjuk egy távoli gépen/gépről, a Wcomputername para- 
méterrel. 


UsrToGrp.exe 


Működését tekintve ez az előző program kistestvére, de csak 
arra képes, hogy a megadott csoportokba az előre elkészített 
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szövegfájl alapján beletegye a már létező felhaszná- 
lókat, illetve ha nem létezik ilyen csoport, létrehozza 
ezt. A maximális extra csak annyi, hogy azon kívül, 
hogy a program a helyi user adatbázisban vagy a tar- 
tományban keresi a felhasználót, lokális csoport ese- 
tén be tud nézni a ,trustolt" tartományokba is, még a csoport- 
ba helyezés művelete előtt. 


CUsrMgr.exe 


Ez a tetszetős sztring a Console User Manager kifejezést rejti 
magában. Meglátásom szerint egy ,Best" vagy ,Cool" jelzőt 
simán elé tehettek volna, mert nagyon jól használható olyan 
dolgokra is, ami a grafikus felületen is problémás néha, főleg 
ha több felhasználói fiók tulajdonságainak egyidejű módosítá- 
sát szeretnénk elvégezni akár egyszerre több gépen is. 





Rémisztő a teljes szintaktika, de látható belőle, hogy négy fő 
terület van: felhasználó létrehozás/törlés, csoport műveletek, 
jelszóműveletek és a felhasználói fiók tulajdonságaival kap- 
csolatos műveletek. 


De inkább embereljük meg magunkat és rémüldözés helyett 
nézzünk egy-két konkrét példát! Most átnevezzük a rendszer- 
gazda fiókot a Gep1 számítógépen: 





Ez a példa pedig berakja a Domain Admins csoportot a távoli 
munkaállomás (TestCli1) Administrators csoportjába. 





Ez a batchfile például három különböző munkaállomáson ál- 
lítja át a lokális rendszergazdai jelszót az általunk megadottra: 





Vigyázzunk a -P kapcsolóval, mert ha kisbetűsen használjuk, 
a jelszó nullázása után egy random jelszót generál, amely fon- 
tos opció speciális esetekre. 

Van viszont egy kifejezetten jelszóresetelő lehetősége is az esz- 
köznek: az alábbi parancs a PDC-re kell hogy irányuljon, és a 
felhasználó fiókján bekapcsolja azt az opciót, amely következ- 
tében a következő belépéskor muszáj lesz a delikvensnek egy 
új jelszót megadnia. 





Létezik a parancs paraméterei között egy SetProperties 
Functions szakasz is, ahol az Addusersnél már megemlített 


fióktulajdonságokon . (Comment, FullName, UserProfile, 
LogonScript, HomeDir, HomeDirDrive) kívül a következő tu- 
lajdonságokat billenthetjük be (-s) illetve törölhetjük (-s): 

AA MustChangePassword 

A CanNotChangePassword 

FA PasswordNeverExpires 

A AccountDisabled 

JAA AccountLockout 

FA RASUSser 


Rcmd.exe 


Ismerős? Az első betű zavaró csak, hiszen a cmd.exe nyilván 
mindenkinek benne van az ujjaiban. Ha ehhez hozzávesszük 
a sokat emlegetett , távoli" kifejezést, meg is vagyunk: ez a 
Remote Command Service. Ami egy kliens-szerver típusú al- 
kalmazást jelent, és sajátossága még, hogy igen barátságtalan a 
súgója, a /? kivételesen és elképesztően semmitmondó, ezért 
álljon itt a használat módjának leírása. 


1. telepítsük fel az remdsvc -install paranccsal szervíz- 
ként. Sajnos ez nem megy távolból, muszáj a vezérelni 
kívánt gépen elindítani (az remdsvc.exe egy külön 
program a Resource Kit/Rcmd mappában) 

2. indítsuk el 5 net start remdsvc (alapból kézi indítású, 
persze átállítható automatikusra az Services MMC-ben) 

3. a kliensen már csak az rcmd.exe szükséges, elindítás 
után a szerver nevével csatlakozhatunk és ettől a pilla- 
nattól a mi parancssorunkat felváltja a távoli gép teljes 
funkcionalitású, interaktív konzolja. A mi sessionünk- 
ből persze a másik gépen semmit se látni, ideális! 

4. Kilépni az exit paranccsal vagy a CTRL--Breakkel tu- 
dunk. 


Válogatott parancsok 


Most n néhány kisebb, ám esetenként gyomorfekély 
megelőző funkciót is betöltő programocska. 





Dumpfsmos.cmd 

Gyakorlatilag megegyezik az ntdsutil FSMO szerepeket lekér- 
dező részével, de kevésbé fárasztó bepötyögni. Enterprise ill. 
Domain Adminként távoli gépeken is használhatjuk. 


GetSid.exe 

Összehasonlítja az elsődleges DC-n és a BDC-n is létező lévő 
(csak) felhasználói fiók SID-jét. Jól jöhet akkor, ha némi zűr 
alakult ki a felhasználói adatbázisban. 


RasUsers.exe 
Kilistázza a Dial-in jogot kapott felhasználókat akár egy gépen, 
akár tartományban. 


NTRights.exe 

Jogokat ad és vesz el, szintén akár távolból is, felhasználó/cso- 
port vonatkozásban. A [0279664] tudásbázis-cikkben tekint- 
hető meg az NTRights által kezelt felhasználókkal kapcsolatos 
összes jog rövidítése. Az alábbi parancs például elveszi a helyi 
gép hálózatból történő elérésének (Access this computer from 
the network) lehetőségét az Everyone csoporttól a DC1 gépen. 





tech.net 


Local.exe, Global.exe, Findgrp.exe 

A futtató gépen illetve a tartományban lévő lokális és globális 
csoportok tagjainak listája. A harmadik pedig ellentéte az első 
kettőnek: egy-egy felhasználó globális és/vagy lokális csoport- 
tagságát mutatja meg. 


Klist.exe 
A KDC által generált jegyek és TGT-k (jegyigénylő jegyek) listá- 
ját nézhetjük meg vele, valamint törölhetünk is az előbbiekből. 


SRVCheck.exe 
Az összes megosztást (ez még nem nagy ügy, a ,net share" is 
tudja), és azok jogosultsági listáit is megmutatja. 


PermCopy.exe 

Megosztás-jogosultságok másolása gépen belül vagy gépek kö- 
zött. Nem véletlenül van szóköz a szerver és a megosztás ne- 
ve között, csak így működik! 


permcopy NYisrvi megosztasi Nisrv2 megosztas2 


Floplock.exe 

Adódhat olyan helyzet, hogy a csoportházirend helyett ezt az 
eszközt kell használnunk a floppy zárolására. Ha egy Win- 
dows 2000 Professional gépen telepítjük a szervízt (pl. az elő- 
ző számban megemlített srvinstw.exe-vel) csak az Administra- 
tors és a Power Users csoport tagjai férhetnek hozzá a floppy 
meghajtóhoz. Server esetén viszont még a Power Users cso- 
port tagjai sem. 


ShowACLs.exe 

Kevéssé hihető módon az Access Control Listeket (jogosultság- 
listákat) mutatja meg. Csak NTFS partíción lévő állományok, 
mappák és mappaszerkezetek vonatkozásában működik. Cél- 
szerűen egy-egy konkrét felhasználó fájlrendszerbeli jogait ér- 
demes vizsgálni vele, hátsó kapuk, figyelmetlenségek után 
nyomozva. 
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UsrStat.exe J 


Ez is egy egészen egyszerű eszköz, de tud valami 1) 
fontosat, amelyet csak , fáradságos" szkriptekkel vagy 

pl. a Hyenaval tudunk elérni. Ez pedig a felhasználók 
alapadatainak kilistázása mellett az utolsó belépésük 

pontos időpontja az adott tartományban. 


Shutdown.exe 

Hálózatunk munkaállomásait, kiszolgálóit egy gépről közpon- 
tilag parancssorból vagy programból is leállíthatjuk, újraindít- 
hatjuk a Remote Shutdown programocska segítségével. Az 
alábbi parancs 10 másodpercen belül (/t:70) leállítja és újrain- 
dítja (r) a TavoliGep1 számítógépet és ezt közli is a felhasz- 
nálóval. A művelet , agresszív" üzemmódban történik meg 
(/c), tehát a Windows zárja az alkalmazásokat anélkül, hogy 
az aktuális folyamatokat elmenthetnénk és nem is tűr 
beavatkozást (/! 


shutdown (iTavoliGepi /r /c /t:10 "Restart lesz 
4 nyomban!" /y 


Lehetséges kombinálni pl. az at (időzítést végző) paranccsal és 
akkor munkanapokon a gépünk egy látványos eksönnel mutat- 
ja meg, hogy mehetünk haza: 


at 18:00 /every:M,T,W,Th,F shutdown /1 "Mara vege" 
$ /y /e 


Kill.exe, Rkill.exe 

A tipikus Resource Kit eszközök, mondhatnánk okosan hátra- 
dőlve, de nem lenne igazunk, mert a kill.exe a minden Win- 
dows 2000 Server tulajdonos számára elérhető Support Tools 
része. A processzek távoli gépen történő legyilkolására hasz- 
nált jótétemény, az Rkill.exe viszont nem, az csak a Resource 
Kitben található meg. Nagyon kényelmes eszköz, először a 
következő paranccsal telepítsük fel a távoli gépen: 


Rkill /install NiTavoliGepi 


Majd jöhet a munka, pl. első körben megtekinthetjük a futó 
processzeket a /view kapcsolóval, és aztán a gyilkolás is el- 
kezdődhet alapesetben a /kill-lel, de ha nem tudjuk az áldo- 
zat PID-jét (Process ID), akkor az /nkill után a processz kö- 
zönséges nevét is használhatjuk. Ha már nincs a programra 
szükség a /deinstall-lal eltávolíthatjuk a távoli gépről. Egyéb- 
ként a PID-ek kiderítésére (ha nem lát(hat)juk a Task 
Managerben) a Support Tools-ban található tlist.exe-t is hasz- 
nálhatjuk, amely szintén megérne egy misét, de az már egy 
másik sorozat témája. 
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Dezeték nélküli LA[ 
— " ! technológiák 


" —— ... és a Windows XP 


A vezeték nélküli LAN-ok és hálózati szolgáltatások kiterjesztik a hálózati felhasználó szabadságát, 
megoldanak több, a fizikai kábelezésű hálózatokkal kapcsolatos problémát, és sok esetben még a há- 
lózattelepítések költségeit is lecsökkentik. E szabadság mellett azonban a zsinór nélküli LAN-ok új ki- 


hívásokat is támasztanak. 


A ma elérhető LAN technológiák standardizáltsági foka és más 
rendszerekkel való együttműködési képessége eltérő. A két je- 
lenlegi piacvezető megoldás a HomeRF és a Wi-Fi (IEEE 
802.11b), melyek közül a 802.11 technológiák szélesebb körű 
ipari támogatottságot élveznek, és alkalmasak mind vállalati, 
mind otthoni illetve nyilvános terek zsinór nélküli LAN- 
igényeinek kielégítésére. A Vezeték Nélküli Ethernet Kompati- 
bilitási Szövetség (Wireless Ethernet Compatibility Alliance) 
célja az, hogy olyan tanúsítványt bocsásson ki, amely egy ter- 
mék 802.11 standardoknak való megfelelését igazolja, segítve 
ezzel a több gyártó által előállított rendszerek zökkenőmene- 
tes együttműködését. 

A kompatibilitási problémák számos kérdést vetnek fel a veze- 
ték nélküli LAN-hálózatok telepítési problémáival kapcsolat- 
ban, de megjelennek még új kihívások a biztonság, a barango- 
lás (roaming) és a konfiguráció területén is. A cikkben ezeket a 
kihívásokat elemezzük, és felvillantjuk a lehetséges megoldá- 
sokat a Windows XP operációs rendszert helyezve a közép- 
pontba, amely fontos szerepet fog játszani a megoldások szál- 
lításában, biztosítva az automatikus konfiguráció támogatását, 
a 802.1x biztonságát és más fejlesztéseket. 


A vezeték nélküli LAN áttekintése 


A nagysebességű vezeték nélküli LAN-ok a helyhez vagy zsi- 
nórokhoz való kötöttség nélkül nyújtják a hálózati kapcsolat 
előnyeit. 

A vezetékes infrastruktúra bővíthető vagy helyettesíthető zsinór 
nélküli kapcsolattal olyan esetekben, amikor a kábelek fekteté- 
se költséges vagy korlátozott, illetve előfordulhat az is, hogy bi- 
zonyos típusú épületekben tiltott a kábelezés, az ideiglenes te- 
lepítések esetében pedig a vezeték nélküli hálózat egyenesen 
kívánatossá válhat. 

Ezen kívül a ,csak új kábelt ne!" — , vezeték nélkül!" — kívána- 
lom terjedése, vagyis a telefon- és az elektromos hálózat egye- 
sítése az otthoni hálózati kapcsolat megteremtésének fő 
mozgatórugójává vált, válhat. 

Az egyre mozgékonyabb felhasználó a vezeték nélküli LAN 
igazi várományosa. A hordozható számítógépek és a vezeték 
nélküli hálózati kártyák segítségével megvalósítható a zsinór 
nélküli hálózatokhoz való mobil hozzáférés, ami a felhaszná- 
lónak utazás közben is biztosítja az információk elérését. 
Enélkül kábeleket kellene magával cipelnie, és mindenhol há- 
lózati csatlakozókra vadászhatna. Fontos rávilágítani, hogy a 
mai standardizált vezeték nélküli LAN-ok nagy sebességgel 


működnek, olyannal, amilyet néhány évvel ezelőtt a zsinóros 
hálózatoktól kívántak. A hozzáférés sebessége több mint 11 
megabit másodpercenként vagy legalábbis 30-szor illetve 100- 
szor gyorsabb, mint a normál modemes vagy vezeték nélküli 
WAN-technológiák esetében. Ez a sávszélesség már elégséges 
egy PC-n vagy mobil készüléken több alkalmazást vagy szol- 
gáltatást használó felhasználó számára is. A jelenlegi fejleszté- 
sek eredményeképpen pedig hamarosan 22 Mbps-ra lesz nö- 
velhető a sávszélesség. 


A vezeték nélküli LAN-technológiák összehasonlítása 


Jelenleg két meghatározó vezeték nélküli LAN-megoldás léte- 
zik: az IEEE 802.11 standard, elsősorban a 802.11b, melyet 
, Wi-Fi" néven emlegetnek, illetve a homeRF munkacsoport ál- 
tal tervezett technológia. A kettő nem kompatibilis egymással 
vagy más vezeték nélküli LAN-megoldásokkal: míg az utóbbi 
kizárólag az otthoni környezetet szolgálja ki, a Wi-Fit ottho- 
nok, kis-, közepes és nagyvállalatok valamint a növekvő számú 
nyilvános vezeték nélküli közterek (repülőterek, kávézók stb.) 
számára tervezték. Számos jelentős hordozható számítógép- 
gyártó Wi-Fi-kártyával szállítja vagy tervezi szállítani termékeit. 
A két megoldást az alábbi táblázatban hasonlítom össze: 


























Szervezet Wireless Ethernet HomeRF Working 
Compatibility Alliance , Group 
(WECA) 
Állapot Szállít (lassan) szállít 
Hatótávolság — 1 15-100 m (46m b 
Sebesség 11 Mb/s 1, 2, 10 Mb/s 
Használhatóság Í otthon, kisvállalkozás, — otthon 
nagyvállalat 
Költség A NIC ára hasonló A NIC ára hasonló 
a HomeRF kártyáéhoz; a Wi-Fi kártyáéhoz; 
a csatlakozási pontok az alapállomás ára 
Br ——— költsége változó . változó 
Biztonság WEP and IEEE 802.1x — NWID/ titkosítás 
Gyártók Több mint 120 tagja 45 szervezet tagja 
van a WECA-nak a HomeRF Working 
Groupnak 
Nyilvános ! A Gartner Group Nincsenek g 
hozzáférési szerint több mint 4000 
pontok az USA-ban ! 
8.8 § 3 D 7? 


A Microsoft a Wi-Fi technológiát tartja a legígéretesebb és 
legszilárdabb megoldásnak a többféle környezetben való 
alkalmazásra. A cikk további része ezzel a technológiával fog- 
lalkozik. 


A vezeték nélküli LAN topológiája 

A vezeték nélküli LAN-ok két alapvető topológiára épülnek, 
melyeket különféle elnevezésekkel illetnek, mint például irá- 
nyított és nem irányított, alárendelt és egyenrangú, illetve inf- 
rastrukturális és ad-hoc jellegű; melyek mind az alapvető topo- 
lógiai különbségekre világítanak rá. Mi az infrastrukturális és 
ad-hoc jellegű fogalompárt fogjuk használni. 

Az inírastrukturális topológia egy meglévő vezetékes LAN- 
hálózatot terjeszt ki vezeték nélküli eszközökre úgy, hogy egy 
központi állomáshoz ún. hozzáférési pontot biztosít, amely 
összeköti a vezetékes és anélküli LAN-t, valamint központi el- 
lenőrként működik az utóbbi számára. A hozzáférési pont 
koordinálja a vezeték nélküli eszközöktől érkezett adatok to- 
vábbítását és fogadását egy adott tartományon belül, — a tarto- 
mányt illetve az eszközök számát a használt vezeték nélküli 
standard és a gyártó termékei határozzák meg. 
Infrastrukturális rendszerben lehet akár több hozzáférési pont 
is, amelyek egy nagyobb területet fednek be vagy egyetlen 
pont egy kisebb területhez, mint például egy lakás vagy kisebb 
épület. 
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5 Infrastruktúrális üzemmód 


Az ad-hoc jellegű topológia esetében a LAN-t maguk a veze- 
ték nélküli eszközök hozzák létre központi ellenőr vagy hoz- 
záférési pont nélkül — minden egyes eszköz közvetlenül kom- 
munikál más eszközökkel a hálózatban. Ez ott lehet hasznos, 
ahol kevés számítógép van, és nincs szükség egy másik háló- 
zathoz való hozzáférésre, például egy lakásban, ahol nincs ve- 
zetékes hálózat, vagy egy konferenciateremben, ahol bizonyos 
csoportok rendszeresen dolgoznak együtt. Ha az ad-hoc jelle- 
gű vezeték nélküli hálózatokat a mai új generációs önálló 
szoftverekkel kombináljuk, az utazó felhasználók dolgozhat- 
nak együtt, fájlokat küldhetnek egymásnak vagy otthon a gye- 
rekek többszereplős számítógépes játékot játszhatnak. 


Destop 
AD HOC Network 4 
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Az ad-hoc üzemmód 


Az infrastrukturális módozat működése 


A vezeték nélküli LAN szóhasználatban , állomásként" 
jellemezett hordozható számítógépnek vagy más intelligens 
eszköznek először az elérhető hozzáférési pontokat és háló- 
zatokat kell azonosítania, amit vagy a hozzáférési pontok ál- 
tal sugárzott jelek detektálásával, vagy egy-egy hálózat után 
próbakeretek segítségével aktívan kutatva tesz meg. 

Az állomás választ egyet az elérhető hozzáférési pontok kö- 
zül, majd egy hitelesítő eljáráson esik át. Miután mindkét fél 
igazolta magát, elindul az összekapcsolódási folyamat, mely- 
nek eredményeképpen a hozzáférési pont és az állomás kö- 
zötti információ- és képességcsere lehetővé válik. A hozzáfé- 
rési pont felhasználja ezt az információt, és megosztja azt a 
hálózat más hozzáférési pontjaival (ha vannak ilyenek), hogy 
tudassa velük az állomás pillanatnyi helyét. Az állomás csak 
akkor tud adatokat átadni és fogadni, miután az összekapcso- 
lódás befejeződött. 

Inírastrukturális módban minden, a vezeték nélküli állomá- 
soktól származó hálózati forgalom egy hozzáférési ponton ke- 
resztül éri el célját mind a vezetékes mind az anélküli LAN- 
ban. (Ez a vezeték nélküli hálózati kártyával működő eszköz 
egymás közötti kommunikációjára is igaz!) 


A hálózathoz való hozzáférés egy vivőérzékelő és ütközéske- 
rülő protokoll segítségével történik. Az állomások egy bizo- 
nyos ideig figyelik az adatok áramlását, mielőtt megkísérelnék 
továbbítani azokat, — ez jelenti a protokoll vivőérzékelő sze- 
repét. Az adatok továbbítása előtt pedig az állomásnak egy bi- 
zonyos ideig várakoznia kell, miután a hálózat , kitisztult". A 
késleltetés, valamint a fogadó állomás által a sikeres fogadás- 
ról küldött igazolás a protokoll ütközést kerülő funkciójának 
eredménye. Érdemes megjegyezni, hogy infrastrukturális 
módban mind a küldő, mind pedig a fogadó minden esetben 
maga a hozzáférési pont; lehetnek ugyanis olyan állomások, 
amelyek nem hallják egymást, de mindketten egy hozzáférési 
pont hatótávolságán belül helyezkednek el — ilyen esetekben 
különösen fontos az ütközések elkerülése. E folyamat keretén 
belül a csomagok továbbítása előtt egy a keretek küldésére 
vonatkozó ,adásigény" (reguest to send) és ,adás vége" (clear 
to send) jelet küldenek az állomások, továbbá minden eszköz- 
nél megtalálható hálózat-foglaltsági táblázat is — szintén az üt- 
közések elkerülése érdekében. Még ha egy állomás nem is 
hallja" egy másik állomás által küldött jeleket, a hozzáférési 
ponttól érkező ,adás vége" üzenetet akkor is észleli, és az 
adott időintervallum alatt tartózkodik az adattovábbítástól. 
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Az egyik hozzáférési ponttól a másikig való baran- 
golás folyamata ebben a szabványban nem teljesen 
tisztázott. Ennek ellenére az iránymutatás és a hoz- 
záférési pontok helyének meghatározására tett kísér- 
letek, valamint az állomásnak más hozzáférési pon- 
tokkal való kapcsolatteremtését célzó újabb összekapcsolódá- 
si folyamat, illetve más, a hozzáférési pontok között alkalma- 
zott gyártóspecifikus protokollok együttesen zökkenőmentes 
átállást tesznek lehetővé. 

A hálózatban lévő állomások közötti szinkronizációt a hozzá- 
férési pont által meghatározott időközönként küldött jelzőke- 
retek biztosítják, amelyek tartalmazzák a hozzáférési pont 
órájának a továbbítás pillanatában mutatott értékét, így a fo- 
gadó állomás ellenőrizheti az eltérést. A szinkronizációnak 
számos oka van, amelyek a vezeték nélküli protokollokkal és 
modulációs sémákkal kapcsolatosak. 


Az ad-hoc jellegű módozat működési mechanizmusa 


Miután tisztáztuk az infrastrukturális mód működési alapelveit, 
az ad- hoc jellegű módozatot akár úgy is magyarázhatjuk, 
hogy itt nincs hozzáférési pont, csak vezeték nélküli eszközök 
vannak jelen a hálózatban. A hozzáférési pont funkcióit, töb- 
bek között az irányjelzést és a szinkronizációt ezúttal egy állo- 
más látja el. Számos értéknövelő szolgáltatás nem érhető el az 
ad-hoc jellegű hálózatban, nem továbbítható például keret két 
olyan állomás között, amelyek nem hallják egymást. 


Kihívások a vezeték nélküli LAN technológiákban 


Mindig jelentkeznek kihívások, amikor egy új hálózati közeget 
vezetünk be új környezetbe, nincs ez másként a vezeték nél- 
küli hálózatok esetében sem. Néhány nehézség a vezetékes és 
anélküli LAN-ok közötti különbségből fakad. Csak egy példa: 
magából a zsinórozott hálózatból adódik egy bizonyos fokú 
biztonság, az adat ugyanis a kábel belsejében áramlik, míg a 
vezeték nélküli hálózatban az adatok a levegőben vagy rádió- 
hullámokon keresztül terjednek. 

Más megoldandó problémák a vezeték nélküli hálózat egyedi 
képességei miatt jelentkeznek. A zsinór nélküliség nyújtotta sza- 
badság magával ragadja a felhasználókat, irodáról irodára, épü- 
letből épületbe, városból városba vándorolnak, mialatt végig 
megszakítás nélküli folyamatos hálózati kapcsolatot várnak el. 
Végül, a hálózattal kapcsolatban mindig is voltak gondok, 
amelyek a bonyolultság fokozódásával — a vezeték nélküli há- 
lózati szolgáltatások hozzáadásával — még összetettebbekké 
váltak. Hiába válik ugyanis a hálózat konfigurálása egyre 
könnyebbé, a vezeték nélküli hálózatok olyan tulajdonságok- 
kal rendelkeznek, amelyek növelik a konfigurációs paraméte- 
rek számát. 


Biztonsági kihívások 

A vezetékes hálózat bizonyos fokú , beépített" biztonsággal 
rendelkezik, amennyiben egy potenciális behatoló csak zsinó- 
ron keresztül tud csatlakozni a hálózathoz, ami leggyakrabban 
a kábelhálózathoz való fizikai hozzáférést jelenti. Ez számos 
biztonsági eljárás segítségével gátolható. 

Ha a hálózat már nem vezetékekből áll, a felhasználók számá- 
ra biztosított szabadság kiterjeszti egy esetleges hacker lehető- 
ségeit is, a hálózat ugyanis elérhetővé válik az előcsarnokok- 
ban, a nem biztonságos váróhelyiségekben, még az épület fa- 
lain kívül is. Otthoni környezetben a hálózat kiterjedhet a 
szomszéd házakra, ha a hálózati készülék a megfelelő bizton- 
sági mechanizmusokat nem vagy nem helyesen alkalmazza. 


A 802.11 szabvány már a kezdetektől lehetővé tett néhány 
alapvető biztonsági eljárást, hogy a megnövekedett szabadság 
kevésbé kedvezzen a lehetséges garázdálkodóknak. A Wi-Fi 
hozzáférési pontok (vagy azok sorozata) például szolgáltatás 
azonosítóval (SSID) láthatók el. Az SSID-t ismernie kell a háló- 
zati kártyának a hozzáférési ponttal (Access Point - AP) való 
kapcsolatteremtéshez, és ily módon folytatnia az adatátvitelt és 
-fogadást a hálózaton. Ez nagyon alacsony szintű biztonság, ha 
egyáltalán annak nevezhető, mert: 


FA az SSID minden NIC és AP számára közismert, 

A az SSID küldése a levegőben történik, még akkor is, ha 
az AP jelzi az irányt, 

A ha az SSID nem ismert, annak eldöntése, hogy az 
összeköttetés létrejöhet-e, helyileg kontrollálható a NIC 
vagy a meghajtó által, és 

A a séma nem biztosítja a titkosítást. 


Bár más problémák is adódhatnak ezzel a sémával kapcsolat- 
ban, már ez is elég ahhoz, hogy a legtöbb alkalmi hackert 
visszatartsa. 

A 802.11 specifikáció további biztonsági elemekkel is szolgál 
a Vezetékessel Egyenértékű Titkosítás (Wired Eguivalent 
Privacy) algoritmus segítségével, amely hitelesítési és titkosítá- 
si szolgáltatásokat nyújt: mindkét funkcióhoz meghatározza 
egy 40 bites titkos kulcs használatát, számos IEEE 802.11 al- 
kalmazás pedig megengedi a 104 bites titkos kulcsokat is. Ez 
az algoritmus védelmet nyújt a lehallgatásokkal szemben, és 
a vezetékes hálózatokéhoz hasonlítható fizikai biztonságot je- 
lent. 

E biztonság alapvető korlátja az, hogy a szabvány nem defi- 
niál a kulcsok kiosztásáért felelős kulcskezelő protokollt, ami 
alapján feltételezhető, hogy a titkos, megosztott kulcsok egy 
biztonságos, az IEEE 802.11-től független csatornán keresztül 
jutnak el az IEEE 802.11 vezeték nélküli állomáshoz. Ez a 
módszer további kihívásokat támaszt, különösen nagyszámú 
állomás részvétele esetén. A hozzáférés ellenőrzése és a biz- 
tonság egy kulcskezelő protokollnak a specifikációba való be- 
vonásáért kiált. A 802.1x szabvány, amellyel később ismerke- 
dünk meg részletesen, ennek a kérdéskörnek a kezelésére jött 
létre. 


A barangoló felhasználó által teremtett kihívások 


Ahogy a felhasználó az egyik hozzáférési ponttól a másikig ba- 
rangol, a hálózati kártyák és a hozzáférési pont közötti össze- 
köttetés elengedhetetlen a hálózati csatlakozás megteremtésé- 
hez. Ez főleg nagy kiterjedésű hálózatok esetében jelenthet bo- 
nyolult problémát, illetve akkor, amikor a felhasználónak alhá- 
lózati vagy adminisztrációs határokat kell átlépnie. Ha a fel- 
használó alhálózati határt lép át, az állomáshoz eredetileg ren- 
delt IP cím nem biztos, hogy érvényes marad az új alhálózat- 
ban. Ha pedig az átmenet adminisztratív tartományok határait 
is érinti, lehetséges, hogy az állomás nem férhet hozzá többé a 
hálózathoz az új tartományban, amely más jogosultságokon 
alapul. 

Egy vállalaton belüli egyszerű barangolás mellett azonban más 
esetek is előfordulhatnak, ahogy mind több repülőtér és étte- 
rem biztosít vezeték nélküli csatlakozást az Internethez, és az 
ilyen típusú hálózati megoldások otthoni környezetben is egy- 
re népszerűbbé válnak. 

Egyre valószínűbbé válik az a szituáció, amikor a felhasználó 
elhagyja irodáját, hogy találkozzon egy másik, kompatibilis ve- 
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zeték nélküli hálózattal rendelkező vállalat képviselőjével. A 
találkozóra igyekezve a felhasználó egy vezeték nélküli hozzá- 
féréssel rendelkező vasútállomáson, étteremben vagy repülőté- 
ren találhatja magát, és szüksége lehet bizonyos adatokra az 
irodából. Hasznos lenne számára, ha hitelesítés után hozzáfér- 
hetne vállalati hálózatához. Amikor megérkezik úticéljához, 
nem biztos, hogy csatlakozhat az ottani helyi hálózathoz, de 
szerencsés lenne, ha az idegen környezetben elérhetné az 
Internetet. Ez a hozzáférés alkalmat teremtene arra, hogy egy 
privát virtuális hálózati csatlakozást hozzon létre saját vállala- 
tának hálózatához. Aztán hazamegy, és az otthoni hálózatá- 
hoz kíván csatlakozni, hogy fájlokat töltsön le vagy nyomtas- 
son ki az esti munkához. Ekkor a felhasználó egy új vezeték 
nélküli hálózatba lépett, amely feltehetően szintén ad-hoc jel- 
legű módban üzemel. A fenti esetben a barangolást alaposan 
át kell gondolni. Ha ugyanis a barangoló felhasználó vezeték 
nélküli állomása bizonyos mértékig nem konfigurálja önmagát, 
a különböző hálózati konfigurációk szükségessé teszik számá- 
ra, hogy maga végezze el az átállítást. 


Konfigurációs problémák 

Most, hogy már rendelkezünk a vezeték nélküli hálózati kap- 
csolattal és a vele járó összetettséggel, még rengeteg 
beállítanivalónk van. Szükség lehet például annak a hálózat- 
nak SSID-beállítására, amelyhez csatlakozunk, esetleg egy sor 
WEP kulcsot kell konfigurálni a biztonság érdekében, — sőt va- 
lószínűleg több sorozatot, ha több hálózathoz kívánunk csatla- 
kozni. Ha pedig van egy inírastrukturális módban üzemelő és 
egy ad-hoc jellegű hálózatunk (mondjuk otthon), valószínűleg 
választanunk kell, hogy melyik konfiguráció váljon alapértel- 
mezetté ott, ahol éppen tartózkodunk. 5 


Megoldások a vezeték nélküli LAN problémáira 
Biztonság - 802.1x 


A Windows XP hálózati csoportja az IEEE-vel, hálózati gyártók- 
kal és másokkal összhangban kifejlesztette az IEEE 802.1x 
szabványt, hogy a WEP által nyújtott biztonságon felül mege- 
rősítse az ilyen jellegű szolgáltatásokat. A 802.1x egy előzetes 
(draft) szabvány a portalapú hálózati csatlakozás ellenőrzésé- 
hez, amely az Ethernet hálózatokhoz való hitelesített hálózati 
hozzáférést biztosítja. A portalapú hálózati csatlakozás ellenőr- 
zése a switch-csel rendelkező LAN-infrastruktúra fizikai tulaj- 
donságait használja a LAN-porthoz kapcsolt eszközök hitelesí- 
téséhez. A porthoz nem lehetséges a hozzáférés, ha nem törté- 
nik hitelesítés. Bár ezt a szabványt a vezetékes Ethernet háló- 
zatokhoz tervezték, a 802.11/Wi-Fi vezeték nélküli LAN-ok 
esetében is alkalmazható. 

A hozzáférési pont — különösen a vezeték nélküli esetekben — 
a hálózathoz való hozzáférés hitelesítőjeként lép fel és egy 
RADIUS szerver szolgáltatásait igénybe véve az ügyfelek jogo- 
sultságait ellenőrzi. A kommunikáció a hozzáférési ponton lé- 
vő logikai ,ellenőrizetlen porton" vagy csatornán át lehetséges, 
ezen keresztül történik a jogosultságok hitelesítése illetve a há- 
lózathoz az ,ellenőrzött porton" való csatlakozáshoz szüksé- 
ges kulcsok kiadása. Az ily módon megkapott, a hozzáférési 
pont és a kliens számára elérhető kulcsok teszik lehetővé az 
ügyfél adatainak titkosítását és a hozzáférési pont számára azo- 
nosíthatóvá tételét. Ezért csatolták a kulcskezelési protokollt a 
802.11 biztonsági funkcióihoz. 

Az alábbi lépések azt az általános megközelítést vázolják fel, 
ahogyan egy hálózathoz vezeték nélkül csatlakozó felhaszná- 
ló gépének hitelesítése történik: 





A Érvényes hitelesítési kulcs hiányában a hoz- 
záférési pont minden rajta áthaladó forgalmat 
megakadályoz, ha pedig hatókörébe egy ve- 
zeték nélküli állomás kerül, a hozzáférési 
pont az állomás felé felszólítást (challenge) 
bocsát ki. 

A Miután az állomás megkapta a felszólítást, saját azono- 
sítójával válaszol, amit a hozzáférési pont a RADIUS 
szervernek továbbít hitelesítésre. 

A A RADIUS szerver ezek után kéri az állomást azonosí- 
tó információkat, meghatározva azt, hogy milyen típu- 
sú azonosítóra van szükség. Az állomás tehát elküldi 
ezeket az adatokat a RADIUS szervernek (a hozzáféré- 
si pont , ellenőrizetlen portján" keresztül). 

A ARADIUS szerver ellenőrzi az azonosító információkat 
és ha a hitelesítés sikeres, egy titkosított hitelesítési kul- 
csot küld a hozzáférési pontnak. A kulcsot csak a hoz- 
záférési pont képes visszafejteni. 

A A hozzáférési pont a hitelesítési kulcsot arra használja, 
hogy a megfelelő kulcsokat biztonságosan elküldhesse 
az állomásnak, beleértve egy unicast és egy multicast 
típusú kommunikációhoz szükséges kulcsot. 

A A biztonság megfelelő szintjének fenntartása érdeké- 
ben az állomás időnként felkérést kaphat, hogy újra és 
újra hitelesítse magát. 


A RADIUS csökkenti a konfigurációs terheket 


A 802.1x megközelítése arra épít, hogy a RADIUS-t széles kör- 
ben alkalmazzák hitelesítésre. A RADIUS szerver le tud kér- 
dezni egy helyi hitelesítési adatbázist, amennyiben az a körül- 
ményeknek megfelelő, vagy a kérést egy másik szervernek tud- 
ja továbbítani. Amikor a RADIUS megállapítja, hogy a gép az 
adott hálózatban hitelesíthető, visszaküldi az üzenetet a hoz- 
záférési pontnak, az pedig lehetővé teszi, hogy az adatforga- 
lom a hálózatba áramoljon. Egy példa lehet erre a következő: 


A A felhasználó egy repülőtéren elindítja hordozható szá- 
míitógépét, amely 802.11-es kártyát tartalmaz. 

A A gép megtalálja az elérhető vezeték nélküli hálózato- 
kat, kiválaszt egyet, és összekapcsolódik vele. 

mA A gép elküldi az őt hitelesítő adatokat a hozzáférési 
pontnak, hogy igazolja, csatlakozhat az adott hálózat- 
hoz. 

A Tegyük fel, hogy a felhasználó ErikBEObigco.com. A 
BigCo vállalat minden felhasználója számára vezeték 
nélküli kapcsolatot vásárolt a világ minden repülőte- 
rén. 

A A RADIUS szerver, amely megkapja a hozzáférési 
ponttól érkező kérést, ránéz a csomagra, és látja, hogy 
az egy, a BigCo-hoz tartozó felhasználótól érkezett. 

A A RADIUS szerver ezután megkér egy BigCo szervert, 
hogy állapítsa meg, vajon az adott személy valódi fel- 
használó-e, illetve rendelkezik-e csatlakozási joggal. 

A Ha a BigCo szerver válasza pozitív, a hozzáférési pont 
átengedheti a forgalmat. 


(Feltehetjük a kérdést, hogy miért kell ezt így bonyolítani, 
amikor egy PCMCIA kártya segítségével GPRS kapcsolatot le- 
het felépíteni, azután VPN-nel elérhető a vállalati hálózat. 
Nos, a különbség a sebesség: a fenti példa ugyanis 11 MBIit-es 
kapcsolatot nyújt az Internet és a vállalati hálózati felé is!!) 
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E Azonosítás egy nyilvános pontról 


Ilyen biztonsági szint eléréséhez a Microsoft Windows XP tar- 
talmaz egy 802.1x ügyfelet, a Windows 2000 $P3 javítócso- 
magjában lévő Internet hitelesítő szolgáltatás (/AS) pedig kibő- 
vült, hogy a vezeték nélküli csatlakozási típusokat és a számí- 
tógép hitelesítést is támogassa. Erről további információ az 
vs Enterprise Deployment of IEEE 802.11 Using Windows XP and 
Windows 2000 Internet Authentication Service" című leírás- 
ban található. A Microsoft több 802.11-gyártóval is együttmű- 
ködött, hogy támogassák ezen eljárásokat a hálózati kártya 
meghajtóikban és a hozzáférési pont szoftvereiben. Ma számos 
élenjáró gyártó eszközeiben 802.1x támogatást nyújt. 


Barangolás - vezeték nélküli barangolás 


A Windows 2000 tartalmazott olyan fejlesztéseket, amelyek 
segítségével egy hálózati kapcsolat megléte megállapítható 
volt. Ezeket egészítette és bővítette ki a Windows XP-ben a ve- 
zeték nélküli hálózat átmeneti természetét figyelembe vevő tá- 
mogatás. 

A Windows 2000 médiaérzékelő — vagyis a hálózati kapcsolat 
felismerésének — képességét az egész hálózat konfigurálásának 
ellenőrzésére használták, illetve a felhasználót értesítették ar- 
ról, hogy a hálózat elérhetetlen. A Windows XP-nél ez a funk- 
ció a vezeték nélküli barangolást teszi még élvezetesebbé azál- 
tal, hogy felismeri az új hozzáférési pontot, a megfelelő háló- 
zati kapcsolat biztosítása érdekében ragaszkodik az újabb és 
újabb hitelesítéshez, és érzékeli az IP-alhálózati változásokat, 
hogy helyes cím legyen használható az erőforráseléréshez. 
Egy Windows XP rendszerben többféle IP-cím konfiguráció 
(DHCP-hez kötött vagy statikus cím) elérhető, és a megfelelő 
beállítást a rendszer automatikusan kiválasztja. Ha az IP-cím 
változik, a Windows XP szükség esetén lehetővé teszi a továb- 
bi konfigurációs változást. A OoS beállítások frissíthetők vagy 
az Internet Explorer Proxy beállítások újból felismertethetők. 
Az automatikus érzékelés és újrakonfiguráció megoldja a háló- 
zatok között barangoló felhasználók legtöbb problémáját. 

Az egyik hozzáférési ponttól a másikig történő barangolás ese- 
tén állapot- és egyéb információk állnak rendelkezésre a 
mozgatandó állomásról, többek között az állomás helyzetéről 
szóló, az üzenetküldéshez szükséges információk valamint az 
összekapcsolódás más tulajdonságai. A hozzáférési pontok át 
tudják adni egymásnak ezeket az információkat, ezért nem kell 
minden átmenetkor újra létrehozni őket. Ezen adatok továbbí- 
tásához szükséges protokollok a szabványban nem definiáltak, 
de erre a célra több vezeték nélküli LAN gyártó közösen fej- 
lesztett egy átmenetek közötti csatlakozást biztosító protokollt 
(Inter-Access Point Protocol - IAPP), amellyel tovább növelték 
a különböző gyártmányú eszközök közötti kompatibilitást. 


Konfiguráció — Automatikus konfiguráció 


A Microsoft együttműködött a 802.11 hálózati kártyák gyártói- 
val is a barangolás még kifinomultabbá tétele érdekében azál- 
tal, hogy a kártyák az elérhető hálózattal való összekapcsoló- 
dása érdekében végzendő konfigurációját automatizálják. 

A vezeték nélküli kártya és NDIS meghajtójának nagyon kevés 
dolga van azon kívül, hogy néhány, az eszköz és a meghajtó 
viselkedését lekérdező és beállító új NDIS objektumfelismerőt 
(OID) támogat. A hálózati kártya megkeresi az elérhető hálóza- 
tokat, és továbbítja azokat a Windows XP-nek, amely rendel- 
kezik egy vezeték nélküli automatikus konfigurációs szolgálta- 
tással (Wireless Zero Configuration), ami elvégzi a NIC adott 
hálózathoz való konfigurálását. 
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E Most már tudjuk, milyen feladata van ennek a szolgál- 
tatásnak 


Ha két hálózat is lefed egy bizonyos területet, a felhasználó 
beállíthatja a kívánt sorrendet, és a gép addig próbálkozik sor- 
ra mindegyik hálózattal, amíg meg nem találja a működőt. Ter- 
mészetesen az összekapcsolódás korlátozható csupán a beállí- 
tott, előnyben részesített hálózatokra is. 

Ha egyetlen 802.11-es hálózat sem található a közelben, a 
Windows XP a hálózati kártyát az ad-hoc jellegű hálózati mód- 
ra állítja be. A felhasználó a vezeték nélküli NIC-et konfigurál- 
hatja úgy is, hogy az ne legyen képes ad-hoc jellegű módban 
működni, illetve akár kényszerítheti is erre. 

Az automatikus konfigurációs és biztonsági fejlesztések integ- 
ráltak, így ha a hitelesítés elmarad, megindul a kísérletezés egy 
másik hálózattal való összekapcsolódásra. 


Összefoglalás 


A vezeték nélküli LAN létező technológia, amelyet a vállala- 
tok, a nyilvános és otthoni felhasználók csak mostanában kez- 
denek felfedezni. E folyamat támogatásához még számos kihí- 
vást kell megoldani. A Microsoft és a 802.11 gyártói mindent 
megtesznek, hogy megfeleljenek az elvárásoknak a Windows 
XP-vel és a Windows 2000-rel. 


Microsoft leírás alapján fordította: 


Lepenye Tamás, MCSE 2000 
lepenyetema.hu 


Biztonságos aláíráskezelű 
alkalmazás II. 


Sorozatunk előző részében áttekintettük az aláíráskezelő alkalmazásokhoz kapcsolódó jogi környeze- 
tet, a tanúsítással kapcsolatos tudnivalókat, valamint az aláíráskezelés biztonságnak alapvető kérdé- 
seit. Jelen rész az elektronikus aláírással és annak feldolgozásával kapcsolatos fogalmakat, jellemzőket 


kívánja megismertetni, különös tekintettel az aláírási szabályzatra. 


Az aláíráslétrehozó és -ellenőrző alkalmazás 


Az aláíráskezelő alkalmazások két típusra oszthatók, illetve két 
alkotórészből állnak, melyek a következők: 

ma aláíráslétrehozó alkalmazás 

ma aláírásellenőrző alkalmazás 


A két alkotórész általában egyszerre van jelen az aláíráskezelő 
alkalmazásokban, hiszen aki aláír, az rendszerint ellenőriz is 
aláírást (lásd levelező alkalmazások, böngészők). Egyes esetek- 
ben azonban előfordulhat, hogy csak az egyik tevékenység van 
jelen az alkalmazásban. Erre példa egy időbélyegző szerver, 
vagy egy számlázó alkalmazás. 

Mindenképp indokolt a két tevékenység szétválasztása, mivel 
funkcionalitásuk és a hozzájuk kapcsolódó biztonsági követel- 
mények alapvetően eltérőek. 


Felhasználói környezetek fajtái 


Legyen szó akár aláíráslétrehozó vagy -ellenőrző alkalmazás- 
ról, e biztonsági követelmények nagyban függnek attól, hogy 
az alkalmazás milyen felhasználói környezetben működik. 
E környezeteknek négy alapvető fajtáját különböztetjük meg: 
A Otthoni környezet 
A Irodai környezet 
ma Nyilvános közeg 
HA Mobil környezet 


Az otthoni környezetben az alkalmazás egy olyan helyen, 
olyan eszközön van elhelyezve, mely az aláíró kizárólagos be- 
folyása alatt áll. Az aláíró megbízik a helyben és az eszközben, 
valamint azokban az emberekben, akik ezekhez rajta kívül 
hozzáférhetnek. Az otthoni környezet tipikus eszköze az aszta- 
li és hordozható számítógép, a személyi asszisztensek, a mo- 
biltelefon. A legtöbb eszköz ezek közül irodai és mobil környe- 
zetben is használható. Az irodai környezetben az alkalmazás 
egy olyan helyen, olyan eszközön van elhelyezve, mely az 
aláíró szervezetének kizárólagos befolyása alatt áll. Elsősorban 
abban tér el az otthoni környezettől, hogy az aláírón kívül 
olyan személyek is hozzáférhetnek az alkalmazáshoz, akikben 
az aláíró korlátozottan bízik meg. Ez igaz a fizikai hozzáférés- 
re, valamint a hálózatira egyaránt, hiszen az irodai eszközök ti- 
pikusan hálózatba kötve működnek. 

A mobil környezetben használatos eszköz egyaránt használha- 
tó egyedül álló módon, illetve csatlakoztatva más eszközökhöz 
és alkalmazásokhoz. Az eszköz és az alkalmazás felhasználó- 
ja bizalmát azok gyártójába, valamint a számára biztosított 
megszemélyesítő eszközébe (pl. SIM kártya) helyezi. 
Nyilvános közegben az aláíróalkalmazás olyan helyen, olyan 
eszközön van elhelyezve, melyhez bárki (vagy igen sokan) 
hozzáférnek. Az eszköz és az alkalmazás az azt működtető 
szolgáltató szervezet kizárólagos befolyása alatt áll. A nyilvá- 
nos közeg tipikus eszköze az Internet terminál, a POS terminál 


ES-C ellenőrzési adatokkal 


ES-T ellenőrzési adatreferenciákkal (ES-CI 


ES időinformációval (ES-TI 
ES időinformációval (ES] 


Aláírási szabályzat 
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Egyéb aláírt 
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Egymásra épülő aláírástípusok 


Az egyes környezeteknek megvannak a maguk sajátosságai, 
melyeket az alkalmazásnak is figyelembe kell venni. Az alkal- 
mazás tervezőinek meg kell határozni, hogy milyen közegben 
történő felhasználásra szánják a terméket, ennek megfelelően 
kell az alkalmazást megtervezni és kifejleszteni, s ezt kommu- 
nikálni kell a felhasználók felé. Ugyanazon bizalmi szint elé- 
réséhez a különböző környezetek esetében más és más imple- 
mentációs módszerekre van szükség. 


és az ATM, de egy Internet Café-ban működő normál asztali 
számítógép is ilyen. . 

Mivel a felhasználó bizalmát az eszközt és alkalmazást mű- 
ködtető szolgáltató szervezetbe kell helyeznie, ezeken jól lát- 
ható módon el kell helyezni a szervezet nevét és egyéb adatait 
(posta és email cím, telefonszám stb.). A szolgáltatónak gon- 
doskodnia kell arról, hogy az eszközt és az alkalmazást senki 
se módosíthassa észrevétlenül. 
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Az otthoni- és irodai-, valamint a mobil környezet- 
ben, az alkalmazások dobozos vagy letöltött szoítve- 
rek lehetnek, melyeket az aláíró (vagy más személy, 
melyben az aláíró megbízik) vásárol és installál fel 
az eszközre. A felhasználónak az alkalmazás előál- 
lítójában kell megbíznia. Ez a következő módszerekkel érhe- 
tő el: 

Dobozos szoftver esetén a csomagolásnak és a dokumentá- 
cióknak, letöltött szoftver esetén a bemutatott online tájékozta- 
tónak világosan jelezni kell, hogy 


FA milyen elektronikus aláírástípusokat és formátumokat 
támogat a rendszer; 

A mely aláírási szabályzatok, illetve aláírási szabályzat- 
formátumok támogatottak; 

A milyen tartalomformátumok megjelenítését támogatja 
az alkalmazás; 

TA milyen szabványoknak és előírásoknak felel meg a 
rendszer; 

A milyen tanúsításokkal rendelkezik az alkalmazás. 


A szoftvert magát is alá kell írni a származás hitelesítésére és 
a sértetlenség biztosítására, s el kell látni az aláírás ellenőrzé- 
sére szolgáló tanúsítvánnyal, hogy a felhasználó meggyőződ- 
hessen az alkalmazás hitelességéről és sértetlenségéről. 


Elektronikus aláírástípusok — érvényességi adatok 


Az elektronikus aláírásnak több típusa létezik, attól függően, 
hogy milyen érvényességi adatok kapcsolódnak hozzá: 


ES - Egyszerű elektronikus aláírás 

ES-T — Elektronikus aláírás időinformációval 

ES-C(bis) — Elektronikus aláírás ellenőrzési adatreferen- 

ciákkal (ez a típus az ES-C-től annyiban tér el, hogy 

időinformációkat nem tartalmaz) 

1 ES-C - Elektronikus aláírás időinformációval és ellenőr- 
zési adatreferenciákkal 

A ES-X - Elektronikus aláírás időinformációval és ellenőr- 

zési adatokkal 


BBB 


Ezek az aláírástípusok egymásra épülnek, egyre több adatot 
biztosítva az aláírás ellenőrzéséhez. 

Az egyszerű elektronikus aláírás is tartalmaz a digitális aláírá- 
son (a lenyomat aláíróalgoritmussal kódolt értékén) kívül aláí- 
rási szabályzat-azonosítót (tipikusan annak OID-jét és lenyo- 
matát), valamint egyéb attribútumokat (pl. aláírásjellemzők), 
melyek az aláírás által szintén védettek. 

Az időinformációval kiegészített elektronikus aláírás a digitális 
aláíráson képzett időbélyegzőt vagy időjelzést tartalmaz. 

Az ellenőrzési adatreferenciákkal kiegészített elektronikus aláí- 
rás ez előbbi kiegészítése, az aláírás ellenőrzésére szolgáló ta- 
núsítványokra és visszavonási állapotinformációkra (visszavo- 
nási listák, OCSP válaszok) vonatkozó referenciákkal. Ezek ti- 
pikusan sorozatszámok és egyedi nevek lehetnek a szolgáltatói 
tanúsítványtárra vonatkozó mutatókkal, mely alapján a tanúsít- 
ványok és állapotinformációk egyértelműen megtalálhatók és 
azonosíthatók. 

Az ellenőrzési adatokkal kiegészített elektronikus aláírás nem- 
csak az előbb említett referenciákat tartalmazza, de magukat a 
tanúsítványokat és visszavonási állapotinformációkat is, így 
azok külső beszerzéséről nem kell külön gondoskodni. Ennek 
alternatívája, ha az ellenőrzési adatok közül csak az aláíró ta- 





núsítványa szerepel az aláírásban, egyéb tanúsítványok és 
visszavonási listák pedig a referencia alapján kerülnek beszer- 
zésre. Ez különösen akkor hatékony, ha az ellenőrző egyazon 
szolgáltató által hitelesített aláírókkal áll kapcsolatban. 


Aláírási szabályzat 

Az aláírási szabályzat különleges, irányító szerepet tölt be az 
aláírás megtételében és ellenőrzésében. Ennek ellenére a fo- 
galom még szűk szakmai körökben sem ismert, így a szabály- 
zat mibenlétének és céljainak összefoglalása mindenképp 
szükséges. 


Az aláírási szabályzat mibenlétét a következő hivatalos definí- 
ciók próbálják tömören visszaadni: 


A , szabálygyűjtemény, mely adott szerződéses és/vagy 
jogi keretek között érvényesnek tekinthető elektronikus 
aláírás készítését és ellenőrzését határozza meg". 
(EESSI] 

A ,olyan technikai és eljárásrendi követelményjegyzék 
az aláírás elkészítésére és ellenőrzésre vonatkozóan, 
mely alapján az aláírás érvényessége megállapítható." 
[CEN/ISSS, ETSI] 


Saját szavaimmal azt mondanám, hogy az aláírási szabályzat 
célja, hogy az aláírást készítő és ellenőrző egyének számára 
egységesen értelmezhető és kezelhető, közös szabálygyűjte- 
ményként meghatározza azokat a feltételeket, amelyek alapján 
egy aláírás érvényesnek tekinthető. 

A definíciókból talán nem derül ki, de az aláírási szabályzat 
egy dokumentum, mely egy adott alkalmazáshoz vagy tranzak- 
ciós környezethez, illetve annak elektronikus aláírási művele- 
teihez kapcsolódik, s amelyet ezen alkalmazás vagy tranzak- 
ciós környezet gazdája szokott előállítani. Az , alkalmazás" itt 
alkalmazási lehetőséget jelent, így ugyanazon (tipikusan dobo- 
Zos) szoftverhez különböző aláírási szabályzatok is kapcsolód- 
hatnak amennyiben eltérő környezetben, eltérő módszerekkel 
használják őket. 

Az aláírási szabályzatnak minden (aláíró és ellenőrző) fél szá- 
mára rendelkezésre kell állni. Szerencsés esetben sok dolguk 
nincs vele, mert a használt szoftver egy az egyben az aláírási 
szabályzatnak megfelelően működik, az attól eltérő működte- 
tést kizárva. Ehhez persze (elméletileg) az lenne szükséges, 
hogy az aláírási szabályzat a fejlesztést vagy integrációt mege- 
lőzően elkészüljön, s követelményspecifikációként szolgálja 
az implementációt. A gyakorlat valójában sokkal inkább az, 
hogy egy valódi követelményspecifikációból kiindulva párhu- 
zamosan zajlik az aláírási szabályzat fogalmazása és a fejlesz- 
tés/integráció, kölcsönösen hatva egymásra. Aminek meg van 
az az előnye, hogy a szabályzat nem szakad el fényévekre a 
megvalósítható megoldásoktól. Az aláírási szabályzat és az al- 
kalmazás ilyen szintű kötődése azonban csak egyedi fejlesz- 
tések esetére jellemző. Amennyiben egy általános célú aláíró 
alkalmazás készül, illetve ha egy dobozos szoftverről van szó, 
azokat több lehetséges működési módra is felkészítik. Ekkor 
az aláírási szabályzat előírásai az alkalmazás konfigurálásán 
és kezelésén keresztül kényszeríthetők ki. 

Ugyanazon elektronikus aláírás megtételére és ellenőrzésére 
nem vonatkozhat két különböző aláírási szabályzat. Ezért is 
kötik aláírási szabályzatot tranzakciós környezetekhez és al- 
kalmazási lehetőségekhez, különösen olyan esetekben, ami- 
kor több különböző szoftver vehet részt e folyamatokban. 





Jogszabályok 
Aláírási szabályzat 
Követelményspecifikáció 


Konfigurációs leírás Követelményspecifikáció 





Alkalmazás 


CI 


Kezelési/útmutató 
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Alkalmazás Alkalmazás 











Tranzakciós környezet 
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Kezelési útmutató Kezelési/útmutató 





E Aláírási szabályzat és kapcsolatai 


Az aláírási szabályzat — mint látható — egyaránt fontos a jogá- 
szok, a fejlesztők és a felhasználók számára. A jogászok belő- 
le tudják megállapítani, hogy az adott ügyletekhez használatos 
aláírás milyen jogi bizonyító erővel bír. Innen nézve szerepe 
felfogható úgy is, mint egy interfész a jog és a technológia kö- 
zött. A fejlesztők és rendszergazdák számára rendelkezései be- 
tartandó fejlesztési és konfigurációs feladatok, a felhasználók 
számára, pedig üzemeltetési előírásként funkcionál. Vagyis az 
aláírási szabályzat egyszerre szinte minden. Csodálatos és el- 
rettentő dokumentum egyidejűleg. Csodálatos, ha arra gondo- 
lok, hogyan sikerülhet leszerelni vele egyidejűleg három jo- 
gászt (saját tapasztalat), akik az egész elektronikus aláírási hó- 
kuszpókuszt és informatikai-műszaki fejtegetést sehová sem 
tudják rakni; s rettenetes, ha arra gondolok, hogy ezt egyszerű, 
jobb sorsa érdemes embereknek meg kéne érteni. Mivel ez 
utóbbi megkövetelése az emberiség elleni bűntettek enyhébb 
esetei közé tartozhat, a szabályzatból külön üzemeltetési leírás 
is készülhet az egyes felhasználási esetekhez kapcsolódóan, 
egy könnyebben emészthető, egyszerűsített formában. 


Az aláírási szabályzat tartalma 


Az aláírási szabályzat az elektronikus aláírás felhasználásának 
feltételeit definiálja egy adott kontextusban. Ez a kontextus le- 
het egy tranzakciós környezet, egy törvényi szabályozás, az 
aláíró fél által felvett szerepkör, stb. Az aláírási szabályzat 
feladata, hogy támogassa dokumentumok elektronikus aláírá- 
sát. Ennek érdekében információkat kell adnia a következő té- 
mákban: 


H Egy bizonyos technológia használata 

mA Engedélyezési szintek 

A Engedélyezési lánc egy szervezeti hierarchián belül 

ma Ellenőrzési lánc egy szervezeti hierarchián belül 

MA Jogi és szervezeti követelmények az üzleti környezet- 
nek megfelelően 

Az üzleti, illetve tranzakciós kontextus definíciója 

A Kötelezettségvállalások típusa 
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Előírhatja speciális aláíró és kulcstároló eszközök, alkalmazá- 
sok használatát (akár az aláíró és ellenőrző környezet típusá- 
nak megfelelően is), megadhatja a használt algoritmusok faj 
ját, a kulcsok hosszát, időbélyegző használatának szükségessé- 
gét, az archiválások mikéntjét, a tanúsítvány visszavonásához 
és ennek közzétételéhez kívánatos feltételeket stb. Tranzakció 
típusonként szabályozhatja a bevonni szükséges szolgáltatókat 
és a bizalom mértékét, meghatározhatja a gyökér tanúsítvá- 
nyokat, tanúsítási láncokat, és ezen láncok tanúsítványai által 
alkalmazott hitelesítési szabályzatokat. 








Az aláírási szabályzat a következő elemekből áll: 
A Az aláírási szabályzat egyedi azonosítója 


(OID) : ; 3 


AA A szabályzat kibocsátójának neve 
mA A szabályzat kibocsátásának ideje 
A A szabályzat felhasználási területe 
A Aláírás ellenőrzési szabályzat 


Az aláírási szabályzat külsőleg definiált elemekre is hivatkoz- 
hat, melyek az aláírási szabályzat részei, de nem ugyanabban 
a dokumentumban lettek meghatározva. Tipikusan ilyen ele- 
mek azok, melyek gyakrabban változhatnak (pl. a bizalmi pon- 
tok listája), s változásuk által így nem feltétlen kell az aláírási 
szabályzat változáskezeléséről gondoskodni. 


Az aláírás ellenőrzési szabályzat 


Az aláírás ellenőrzési szabályzat, az aláírási szabályzat része- 
ként, az aláírók és aláírás ellenőrzők számára az elektronikus 
aláírás feldolgozására vonatkozó technikai szabályokat speci- 
fikálja. Szabad formátumú szövegként vagy gépileg feldolgoz- 
ható nyelvként (pl. ASN.1) is leírható. 


A következő információkat kell tartalmaznia: 

A Szabályok a tanúsítási lánc ellenőrzésére és felépíté- 

sére 

A Szabályok a visszavonási állapot információk kezelésé- 
re (pl. CRL, OCSP) 
Szabályok az idő információk, időjelzések, időbélyeg- 
zők kezelésére 
Aláírás ellenőrzési adatok, melyeket az aláíró biztosít 
Aláírás ellenőrzési adatok, melyeket az aláírás-ellenőr- 
zőnek kell beszerezni 
Az aláírások megtétele számára engedélyezett időtar- 
tam (ami előtt és után a szabályzatra hivatkozva tilos 
aláírni) 
Az elfogadott kötelezettségvállalási típusok listája 
Az aláíró szerepekre vonatkozó szabályok 
Az algoritmusokra és kulcshosszokra vonatkozó meg- 
kötések 


B B8 § 


B8 B 


Az aláírási szabályzat és az aláírás 

Az aláírás ellenőrzésére használandó aláírási szabályzatnak 
egyértelműen azonosíthatónak kell lenni az ellenőrző fél szá- 
mára. Ennek érdekében az aláírónak félreérthetetlenül jeleznie 
kell, hogy milyen aláírási szabályzatnak megfelelő módon ké- 
szítette és várja el az aláírás értelmezését. Az aláírási szabály- 
zatra való utalás egyaránt lehet explicit vagy implicit. 

Explicit esetben az aláírási szabályzatra való utalás és az aláí- 
rási szabályzat által meghatározott kötelezően és opcionálisan 
választható paraméterek (mint a kötelezettségvállalási típus) az 
aláírás részévé válnak. Az aláírási szabályzatra annak egyedi 
azonosítója alapján lehet utalni, a biztonság kedvéért a sza- 
bályzat lenyomatának mellékelésével. Opcionálisan az aláírás 
tartalmazhatja az aláírási szabályzat fellelhetőségének címét is 
(URL). 

Implicit esetben az aláírói dokumentumból, annak valamilyen 
attribútumából vagy az aláírásjellemzőkből, illetve egyéb do- 
kumentumokból (jogszabályok, szerződéses feltételek, egyéb 
szabályzatok) következik az alkalmazandó aláírási szabályzat. 
Mindkét esetben az utalásnak az aláírás által védett módon kell 


megvalósulnia. 
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Az aláírási szabályzat és az aláíráskezelő alkal- 
mazás 


Az aláíráskezelő alkalmazásnak kezelni kell tudni 
egy vagy több az aláíró által alkalmazni kívánt aláí- 
rási szabályzatot. Az alkalmazásnak az aláírási sza- 
bályzat előírásai szerint, az által vezérelve kell működnie, az 
aláírót és az ellenőrzőt a szabályzat előírásainak megfelelően 
bevonva az aláírás és ellenőrzés folyamatába. 

Explicit szabályzatra való utalás esetén az alkalmazás több 
szabályzat szerint is; automatikusan és az aláírás megtétele 
után jelentős idővel is ellenőrizni tudja az aláírást, s az aláírás 
érvényessége egyértelműen bizonyítható. 

Implicit esetben az automatikus aláírás ellenőrzés csak egy 
szabályzat szerint tud megvalósulni (egy bizonyos szerződé- 
ses, jogszabályi környezetnek megfelelően, mely egyedül al- 
kalmazható) vagy emberi közreműködéssel (amely eldönti 
melyik aláírási szabályzat alkalmazható a több lehetséges kö- 
zül), hiszen az alkalmazástól nem várható el az implicit uta- 
lások értelmezése, azaz annak eldöntése, hogy melyik aláírá- 
si szabályzat szerint működjenek egy adott aláírás esetében. 
Az aláírás létrehozó alkalmazásnak csak az aláírási szabályzat 
által ismert, az adott környezetben és esetben, az adott aláíró 
által választható paramétereket szabad felajánlani. 

Az aláírás ellenőrző alkalmazásnak fel kell ismerni az alkal- 
mazandó aláírási szabályzatot, és annak megfelelően kell vég- 
rehajtania az aláírás ellenőrzését. 


Terminológia 
Digitális aláírás 
A lenyomat aláíró algoritmussal kódolt értéke. 


Időjelzés 

Az aláírás aláíró által jelzett időpontja, mely a hitelesség 
érdekében egy független szolgáltató által megbízható 
módon rögzítésre (archiválásra) kerül, az aláírással 
együtt. 


Aláírás-ellenőrzési folyamat 
Olyan folyamat, amely érvényesít egy elektronikus aláí- 


rást az aláírási (esetleg hitelesítési vagy szolgáltatási) sza- 
bályzat követelményeinek megfelelően. 


Tanúsítási lánc 

Egymást hitelesítő tanúsítványok hierarchiája (láncola- 
ta). A hierarchia alján az aláíró tanúsítványa szerepel, 
felette az e tanúsítványt aláíró hitelesítő egység saját ta- 
núsítványa, felette az e hitelesítő egységet hitelesítő má- 
sik hitelesítő egység saját tanúsítványa. A sorozat egé- 
szen a gyökér hitelesítő egységig ismétlődhet, amely a 
lánc legteteje. 


Érvényesítési adatok 

Olyan az aláírást kiegészítő adatok, amelyek annak el- 
döntéséhez szükségesek, hogy egy elektronikus aláírás 
megfelel-e az aláírási szabályzat követelményeinek. 
Tartalmazhat tanúsítványokat, visszavonási állapotinfor- 
mációkat (az aláíróra és a hitelesítés-szolgáltatóra vonat- 
kozóan), továbbá időbélyegzés-szolgáltatóktól származó 


időbélyegzéseket, és időjelzéseket. Az érvényesítési 


adatnak igazolnia kell azt, hogy az aláírás létrehozása- 
kor az ott felhasznált teljes tanúsítási lánc érvényes volt. 


Gyökér tanúsítvány 

Olyan tanúsítvány, amit már nem hitelesít újabb tanúsít- 
vány. A benne szereplő nyilvános kulccsal ellenőrizhető, 
ami miatt önhitelesített tanúsítványnak is nevezik. A hi- 
telességét valójában nem önmaga adja, hanem más mó- 
don gondoskodnak erről. Például lenyomatát belefoglal- 
ják az aláírási szabályzatba, az alkalmazásba, illetve új- 
sághirdetésekben közzé teszik. 


Bizalmi pont 

A bizalmi pont a tanúsítási lánc legfelső eleme. Gyakor- 
latilag egy gyökér tanúsítványból és egyéb kiegészítő 
adatok összességéből áll. Az iránta való bizalom az álta- 
la hitelesített összes (szolgáltatói és végfelhasználói) ta- 
núsítvány tekintetében is bizalmat jelent. Az ellenőrző 
által elismert bizalmi pontokat az ellenőrző is gyűjtheti 
egy biztonságos tárban, és az aláírási szabályzat is meg- 
határozhatja. Ez utóbbi esetben, ha az aláírási szabályzat 
által elismert bizalmi pontok változnak, akkor az aláírá- 
si szabályzatnak is változni kell. A szabályzatban az 
egyes kötelezettségvállalási típusokhoz különböző bizal- 
mi pontokat lehet rendelni. 


Szerepkör 

Olyan tulajdonsága az aláírónak, amelynek segítségével 
egy szervezetben vagy a közösségben betöltött feladat- 
és jogköre, speciális szerepe azonosíthatóvá válik 


Kinyilvánított szerepkör 
Olyan szerepkör, melyet az aláíró állít, de külső fél által 
nincs hitelesítve. 


Hitelesített szerepkör 
Olyan szerepkör, amelyet külső fél hitelesített. Tipiku- 
san tulajdonságtanúsítványokat használnak erre a célra. 


Almási János 
Janos.Almasi€ohu.ibm.com 


Exchange é00Ú scripting 


Az ismeretlen eszköz 


A windows scripting használatával nem csak a unix adminok kiváltsága a feladatok 
egyszerű megoldása rövid segédprogramokkal. Az exchange is támogatja a scriptek 
használatát, amivel sok gondot le tud venni a vállunkról. Lássuk! 


Habár a címben exchange szerepel, valójában a standard 
SMTP szervizben is megtalálhatóak ezek a lehetőségek. Sőt, 
még a Windows 2000 Professionalra telepíthető SMTP kiszol- 
gáló is tudja ezeket. 


Miket is? 

Az emailek továbbítására az SMTP protokoll szolgál. A feladó, 
a levelezőkliens, és a célszerver között tetszőleges számú 
SMTP szerver szerepelhet, ezek ,tárold és továbbítsd" elven 
működnek. A szerverünk az üzenet küldése/fogadása közben 
több fontos pontban képes általunk írt eljárások hívására, ezek 
többsége azonban C---4 (cs, delphi, stb) nyelvek használatát 
igényli. A CDO - Collaboration Data Objects [cdo) — azonban 
lehetőséget ad bizonyos eseményeknél scriptek hívására is. A 
CDO egy COM-osztályokból álló csomag, amely kifejezetten 
Internetüzenetek készítésére és módosítására készült. Minden 
Windows 2000 operációs rendszeren elérhető, az Exchange 
2000 telepítésekor egy exchange változat — a CDOEX -— cseré- 
li le a CDO-t, de ez a változat felülről kompatibilis a CDO-val. 
A CDO egyetlen SMTP transport eventet támogat, az 
Onarrivalt. Az OnaArrival — nevének megfelelően — a levél 
beérkezése után hívódik meg. Paraméterezése a következő 
(VBScript esetén) [onarrivall: 





Az első paraméterben jön maga az üzenet, az EventStatus pe- 
dig azt tartalmazza, hogy mi történjen a kapott levéllel. Ezt a 
script-ben megváltoztathatjuk, a lehetséges értékek: 


0 - futtassa a következő eventet 

1 - feldolgozás vége, a következő event már ne fusson le 
2 - ne kézbesítse az üzenetet (eldobja) 

3 - az érkezett levelet tegye a BadMail folderbe 


Az első két esetben a levelet kézbesíti a címzett felé, a 2-3 ér- 
tékeknél viszont a címzett nem kapja meg a levelet. 


The power of OnArrival 


Szóval itt van a kezünkben a beérkezett levél, és eldönthetjük, 
mi történjen vele. A lehetőségek gyakorlatilag korlátlanok: a 
kapott Msg objektum tulajdonságain és metódusain keresztül a 
manipulálhatjuk a beérkezett levelet. A scriptből tetszőleges 
COM / ActiveX objektum létrehozható — akár újabb levél is 
küldhető —, a használt scriptnyelv pedig bármi lehet, amit a 
Scripting Host támogat (VBScript, JScript, akár Perl is). 
Néhány felhasználási lehetőség: 

A Bejövő levelek archiválása: akár file-ba, akár SOL adat- 

bázisba (ADO segítségével). 
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A Levelezőlista: a beérkező leveleket továbbküldeni a lis- 
tatagoknak, megoldani a subscribe/unsubscribe kezelé- 
sét és kész is (esetleg még webes felületet is rittyentünk 
stb. és akár pénzért is árulhatjuk :-) ) 

A Spamszűrés: a bejövő levelek címében / törzsében bi- 
zonyos szavak keresése, találat esetén a kézbesítés 
megszakítása — esetleg egy gyűjtő címre továbbítása a 
címzett cseréjével. 

A Automatikus válasz a beérkező levelekre: ahogy a ,na- 
gyok" csinálják: ,Levelét az xy corporation fogadta. 
Munkatársunk z napon belül megkeresi Önt. További 
kérdés esetén kérem hivatkozzon a xxxxx azonosító- 
ra."— ahol az azonosítókiosztás is automatizálható. 

A Order processing: külső rendszerekből -— akár saját 
webünkről, egy megrendelés oldalról — emailben érke- 
ző adatok feldolgozása, adatbázisba illesztése. 

A Workflow management. 


Fontos megemlíteni, hogy OnaArrival eseményben TNEF- 

üzeneteket kezelni igen körülményes, mivel először a kapott 

levelet dekódolni kell. A TNEF-beállítás sok gondot okozott ré- 

gebben - ekkor az üzenet egy winmail.dat nevű csatolt file- 

ként érkezik meg -, véleményem szerint mára minden 
Exchange szerveren ki van kapcsolva 
ez az opció (0241538). 


Bejövő és kimenő Konkrét felhasználás: read receipt 
eltávolítás 

levelek feldolgozása. Az Exchange 2000 / Outlook 2000 
páros használatakor az Exchange ké- 

7 automatikusan. rés nélkül küldi a read receipteket a 


beérkező levelek olvasásakor (ameny- 
nyiben a küldő kérte), ezt nem is lehet 
szabályozni. Ez sok esetben nem kívá- 


natos, ezek a kérések azonban a bejövő levelekből eltávolít- 
hatóak. 

A read receipt kérések MIME üzenet esetén a levél fejlécében 
utaznak, a fejlécet Outlookban a levél tulajdonságai között 
nézhetjük meg. A kérés a következő formában található: 





A kérések eltávolításához a fenti két sort kell az üzenetből el- 
távolítani. A levél fejlécét az Msg objektum Fields tulajdon- 
ságán keresztül érhetjük el, az egyes mezők nevei a 
,urn:schemas:mailheader:" névtér elemei. A read receipt kérés 
törléséhez a fenti két mezőt kell törölni a fejlécből. Mivel nem 
tudjuk, hogy melyik fajta kérés érkezik, biztosra menve mind- 
kettőt töröljük. 
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Exchange 2000 scripting 


A megfelelő VBScript program: 





A script file megvan, már csak értesíteni kellene az SMTP szer- 
vert, hogy futtassa le a scriptet, ha levél érkezik. Az Event 
Sinkek managelésére a Microsoft által készített smtpreg.vbs 
script — viszonylag — kényelmes megoldást ad: 





A fenti példában a minden címre érkező (rcpt to-") levélhez 
rendeltük hozzá a fenti scriptet, RRRSink néven. Ezután az 
smip szerver által fogadott levelekből eltávolítja a read receipt 
kérésre vonatkozó sorokat. Amennyiben azt szeretnénk, hogy 
csak bizonyos címzettnek érkező levelekre ne küldjön a szer- 
ver automatikus választ olvasáskor, két választásunk van: 


(A A script-ben ellenőrizzük a címzettet (az Msg.To mező 
ellenőrzésével), és csak ennek megfelelően töröljük az 
említett két mezőt 

IH Nem minden címzetthez rendeljük hozzá a scriptet (a 
lenti példában a scriptünk csak , valakiGojdomain.hu" 
számára küldött levelek érkezése esetén fog elindulni: 





A teljes cikk itt megtalálható: [exscript] 


Felhasználás 2.: lábléc illesztése kimenő levelekre 


Naponta többször visszatérő kérdés a Microsoft hírcsoporto- 
kon az, hogyan lehetne láblécet (disclaimer) rakni a kimenő le- 
velekre. Léteznek erre fizetős megoldások, de a kihívásokat 
szerető rendszergazda természetesen a saját megoldást favori- 
zálja! 

Természetesen erre a feladatra is lehet scriptet készíteni, amely 
az üzenet tartalmához fűzi a láblécet: 








Sajnálatos módon exchange használatakor a kimenő levelekre 
nem hívódik az smtp OnaArrival event [exscript]. Mit lehet 
ilyenkor tenni? A megoldás: a kimenő leveleket egy másik 
SMTP-szerveren keresztül kell küldeni! Az Exchange-ben ez 
megoldható — , smart host" beállítás -, SMTP-szervert pedig két 
módon is telepíthetünk: egy külön w2k szervert (célszerűen 
DMZ-ben), ekkor a második szerverre kell a scriptet telepíteni, 
így ott a kimenő leveleinket is tudjuk az OnArrival segítségével 
kezelni. 

Másik lehetőség: egy második SMTP-szerver példányt kell tele- 
píteni az Exchange-et futtató gépre, és ezen keresztül küldeni 
a kimenő leveleket. Ebben az esetben a következőkre kell fi- 


gyelni: 


A a második SMTP-szervert az alapértelmezett 25-ös port 
helyett másik portra kell konfigurálni 

TA az Exchange-ben a Smart Host beállítás mellett a kime- 
nő levelek TCP portját is be kell állítani az előző pont- 
ban megadott portra 

A az smtpreg.vbs futtatása során a használt SMTP- 
szerverpéldány számát 1-ről 2-re kell változtatni 


Fontos: az egyre jobban terjedő digitálisan aláírt levelek tartal- 
mát nem tanácsos megváltoztatni, mivel ez az aláírás hiteles- 
ségét elrontja. 


Tapasztalatok 


Véleményem szerint a bejövő és kimenő levelek automatikus 
kezelése nagymértékben segítheti a munkát. Cégünknél egy 
script végzi a külső forrásból érkező megrendeléseket — adat- 
bázisba illesztés, értesítő levél visszaküldése — amivel napi 1-2 
óra munkát is megtakarítunk. 

Jelen cikkben csak néhány ötletet kívántam adni a lehetséges 
felhasználásokra. A linkek — és a google — tanulmányozása so- 
rán olyan megoldásokat is lehet találni, ami esetleg eszünkbe 
sem jutna. 


Karakas Gyula 
Vamsoft Kft. 
gyula.karakas(ovamsoft.com 


tech.net 
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Adatbáziselérés modellezése ul 


Gyakori probléma, hogy a tesztkörnyezetben remekül működő adatbázis-alkalmazá- 


sok éles működés közben rengeteg galibát okoznak, a felhasználók összeakadnak, a 
terhelés növelésével a válaszidő drasztikusan megnő. Ilyenkor óriási összegeket for- 
dítunk a hiba felderítésére és kiküszöbölésére. Ez azonban elkerülhető lenne egy kis előretekintéssel... 


Aki informatikával foglalkozik, óhatatlanul is találkozott már 
olyan fogalmakkal, mint holtpont (deadlock), kölcsönös kizá- 
rás, tranzakciókezelés stb. Amíg ezeket a dolgokat csak tanul- 
ja az ember, sokszor értelmetlennek, haszontalannak tűnnek, 
igazi hasznukat csak később, a való életben tapasztaljuk meg, 
általában saját bőrünkön. 

Akkor azonban már többnyire késő. A hónapokon (netán éve- 
ken) keresztül fejlesztett adatbázis-alkalmazás remekül műkö- 
dött a fejlesztői környezetben, viszont az éles működés során 
váratlan működéseket produkál. Ilyenkor többnyire kétségbee- 
setten és értetlenül állunk, hiszen mi mindent jól csináltunk... 
Egészen biztos ez? Miért viselkedik másképp a rendszerünk 
éles használat során? Mi változik a tesztkörnyezethez képest? 

A válasz egyszerű, mégsem triviális felkészülni rá: a terhelés. 
Sok felhasználó egyszerre próbál tömegesen elérni adatokat, 
ráadásul többnyire működés közben az adatbázis mérete is 
többszörösére növekszik a tesztadatbázishoz képest. Termé- 
szetes lépés, hogy a hardverkonfigurációt bővítjük, sok esetben 
azonban a szoftvert nem készítjük fel a terheléstöbbletre. 


Szempontok az adatbázis tervezésénél 


Az adatbázis tervezésekor szükségképpen fellépnek különbö- 
ző kényszerek (constraints), amelyek a feladat jellegéből követ- 
keznek, és általában egyszerűen megfogalmazhatók. Ezek a 
kényszerek lehetnek értékalapúak, amelyek valamely adatbá- 
zis-mezőt — egy konkrét értékhez kötik, például 
SZUL DATUM31900. 

Az értékfüggetlen kényszerek azt írják elő, hogy egy attribú- 
tumtól hogyan függnek más attribútumok értékei. A legfonto- 
sabb ide tartozó kényszer a funkcionális függőség. Ez azt 
mondja meg, hogy egy adatbázis valamely A attribútuma/attri- 
bútumhalmaza meghatározza B-t, vagyis ha a reláció valamely 
két elemében az A attribútumok megegyeznek, akkor meg kell 
egyezniük a B attribútumok értékeinek is. 

A funkcionális függőség lehet eseti, amikor konkrét értékekre 
teljesül a függőség, de ez nem törvényszerű, sőt az is előfordul- 
hat, hogy csupán esetlegesen függnek össze az attribútumok. 
Az egyedi függőségnek tervezési szempontból nem igazán van 
jelentősége, a gyakorlati felhasználás során a valós, mögöttes 
tartalmat ismerve nyerhet értelmet. Ezt használják ki például a 
különböző adatbányászati algoritmusok, amelyek a szemanti- 
kából közvetlenül nem következtethető tulajdonságokra vetíte- 
nek rá (lásd alább). 

Érdemi funkcionális függőségről akkor beszélünk, ha a függő- 
ség mindig fennáll, minden olyan relációra, amely tartalmazza 
a függőségben lévő A és B attribútumhalmazokat. Ezek több- 
nyire redundáns információkat eredményeznek az adatbázis- 
ban, és nagyon fontosak a tervezés szempontjából is. 


Adatbányászat és adatbázis-lekérdezések 


Tapasztalataim szerint sokak szemében nem világos a két foga- 
lom közötti különbség, ezért úgy érzem, mindenképp szüksé- 
ges néhány szó kitérőt tenni ez irányba. 

Az adatbázis-lekérdezések során általunk is ismert kapcsolato- 
kat (relációkat) modellezünk az adatbázis elemei között. A ter- 
vezés során felmérjük, a megrendelőnek milyen igényei van- 
nak, és megpróbálunk egyre pontosabb modellt felállítani az 
adott problémához. A modellel szemben több fontos követel- 
mény is fennáll, egyrészt tükröznie kell a felhasználó által leírt 
valós rendszer struktúráját, másrészt kellően formálisnak és ke- 
zelhetőnek kell lennie ahhoz, hogy az általunk fejlesztett szoft- 
verek (vagy más alkalmazások) szót értsenek vele. Néhány to- 
vábbi szempontot említek még a későbbiekben, most azonban 
áttérnék egy picit az adatbányászatra. 

Az adatbányászat célja rejtett összefüggések feltárása az adat- 
bázis (adattárház) elemei között. Nagyon fontos, hogy nem 
csupán az adatokkal dolgozik, hanem azokhoz időpontokat is 
rendel, azaz fontos szempont az is, hogy az adatok mikor ke- 
rültek a rendszerbe. Gyakori, hogy nem is egyszerűen egy-egy 
adatbázissal dolgoznak az adatbányászok. Ennek oka az, hogy 
célszerű különválasztani az operatív (mindennapi használat- 
ban lévő) adatbázist az összefüggések feltárására szolgáló 
adattárházaktól. Másrészt ily módon több adatbázis adatai is 
bekerülhetnek egyetlen tárházba, így pl. egy cég különböző 
adatbázisait (fejlesztői, marketinges, HR stb.) is egy időben, 
egy helyen dolgozhatjuk fel. 

Az adattárházak megjelenésével az is lehetővé válik, hogy csak 
az adatbányászat szempontjából hasznosnak vélt adatok kerül- 
jenek be oda, így az adatbányászat szó valódi értelmére is fény 
derül: a valódi bányászat során is rengeteg törmeléket, haszon- 
talan anyagot kell eltávolítani ahhoz, hogy a gyémántot vagy 
aranyat megtaláljuk. 

Összefoglalva tehát az adatbányászat során olyan információ- 
kat szeretnénk a felszínre hozni, amelyekről pontosan nem 
tudjuk, mit keresünk, tehát nem tudjuk megfogalmazni egy 
egyszerű lekérdezéssel. Természetesen az így kapott informá- 
ciókat ezek után még értelmezni is tudni kell, ehhez külön, az 
adott szakterületen jártas szakemberekre van szükség. 

De ez már egy következő cikksorozat témája lehet(ne)... 


Mielőtt azonban visszatérnék az adatbázis-tervezés problémái- 
hoz, lássunk egy példát az adatbányászatra, hogy valóban lás- 
suk, miért is van rá szükség. Tekintsünk egy óriási üzlethálóza- 
tot, amelynek sok-sok üzlete van, és minden üzletben a termé- 
kek széles skáláját kínálják. Egyszerű adatbázis-lekérdezések 
segítségével választ kaphatunk a következő kérdésekre: 

A Hány pár rózsaszín zoknit vásároltak az elmúlt évben? 

A Átlagosan hány liter tejet vettek a kelet-magyarországi 

üzletekben naponta? 
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HA Melyik termék az, amelyik épp nincs készleten vala- 
mely üzletben? 
RA stb. 


Jól látszik, hogy ezek konkrét, kézzelfogható kérdések, ame- 
lyeket gyakorlott adatbázis-programozóként nem túl bonyolult 
lekérdezések formájában megadni. Adatbányászat segítségével 
azonban az alábbi dolgokra is fényt deríthetünk: 


A Milyen összefüggések vannak az egyes termékcsopor- 
tok között? (Például: aki paprikás chipset vásárol, az 
többnyire sört is vesz.) 

A Milyen összefüggések vannak a vásárlói szokásokban? 
(Például: aki ma gyermekbiciklit vásárol, az valószínű- 
leg 5 éven belül sétálómagnót is vesz.) 

ma stb. 


Jól látszik, hogy ezek a kérdések eléggé ,megfoghatatlanok", 
formálisan nem igazán írhatók le. Az adatbányászat különbö- 
ző algoritmusok segítségével, az adatbázis átvizsgálásával 
ezekre is választ adhat. 


Adatbázis-relációk normál formái 


Az adatbázis-tervezés során akarva-akaratlanul is viszünk re- 
dundanciát a rendszerbe. Az úgynevezett normál formák 
(Normal Forms, NF) azt adják meg, hogy mennyi redundanciát 
tartalmazhat egy adott relációs forma. 

A ONF (0. normál forma) a normalizálatlan relációs sémát jelö- 
li, azaz a relációs sémában található attribútumok közül lega- 
lább az egyik nem atomi (hanem összetett). Egy attribútum 
összetett, ha több részre bontható, például egy SZEMELY NEV 
attribútum az alkalmazások jelentős részében felbontandó ve- 
zeték- és keresztnévre. 

Az 1NF (1. normál forma) már normalizált reláció, azaz min- 
den attribútuma atomi. Az előző példában tehát külön attribú- 
tumként szerepel a VEZETEKNEV és a KERESZTNEV. Ez a nor- 
mál forma csupán kiindulási alapként szolgál a magasabb nor- 
mál formákhoz, önmagában nem használatos. 

A továbbiakhoz szükség lesz két alapvető fogalomra. Elsődleges 
kulcsnak nevezzük az adatbázis azon attribútumait, amelyek 
valamely kulcsnak részei. Ennek megfelelően másodlagosak 
azok az attribútumok, amelyek egyetlen kulcsnak sem részei. 
A 2NF (2. normál forma) olyan INF relációs sémát takar, 
amelynek egyetlen másodlagos attribútuma sem függ kulcs va- 
lódi részhalmazától. Ebből az következik, hogy ha egy séma 
csak egyszerű (egyetlen attribútumból álló) kulcsot tartalmaz, 
csak 2NF lehet. Igaz ez akkor is, ha a séma minden attribútu- 
ma elsődleges. 

Egy INF reláció pedig akkor 3NF is egyben, ha egyetlen má- 
sodlagos attribútuma sem függ tranzitívan kulcstól. Tranzitív 
függőségről akkor beszélünk, ha X és Y két attribútumhalmaza, 
A pedig egy attribútuma a sémának. A akkor függ tranzitívan X- 
től, ha XY, YP.X, YA és A nem eleme Y-nak. Vagyis: Az Y att- 
ribútumhalmaz függ X-től (de ez viszont nem igaz), A pedig 
függ Y-tól. 

Egy másik megközelítés szerint egy INF séma akkor 3NF is 
egyben, ha minden XA; X nemtriviális függőség esetén vagy X 
szuperkulcs, vagy A elsődleges attribútum. 

(Egy XY függőség függőség triviális, ha az X attribútumhalmaz 
részhalmaza az Y-nak.) 

Végül lássuk a BCNF-et (Boyce-Code Normal Form): egy relá- 
ciós séma akkor BCNF, ha 1 NF, és minden X kulcsára és tetsző- 


leges A attribútumára igaz, hogy A nem függ tranzitívan kulcs- 
tól (egyáltalán nincs kulcstól való tranzitív függőség). 
Bizonyítható, hogy a BCNF sémára illeszkedő relációk egyál- 
talán nem tartalmaznak redundanciát (legalábbis a funkcioná- 
lis függőséget illetően). 

Az adatbázisunk akkor őrzi meg a fenti tulajdonságokat, ha a 
benne szereplő minden reláció illeszkedik az adott normál for- 
mára. Az alábbi ábra egy szemléletes áttekintést ad az egyes 
normál formákról: 





a 


Relációk normál formái 


Tranzakciókezelés 


A fenti tulajdonságok megléte komoly tervezési döntéseket igé- 
nyel, ezeket most szintén nem részletezném, a szakirodalom 
igen sokoldalúan foglalkozik ezzel a témakörrel. 


Tranzakciókezelés 


Ha az adatbázisunk készen van, jöhet az elérőfunkciók meg- 
valósítása. Ami persze nem is olyan egyszerű feladat. Egy-két 
lekérdezés itt, néhány beszúrás ott, és máris problémák töm- 
kelegével állunk szemben. Az alkalmazásunk lelassul, időn- 
ként időtúllépés (timeout) miatt elszáll, sőt akár bizonyos ese- 
tekben végtelen ciklusba is kerülhet egy-egy felhasználó ki- 
szolgálása. 

Most igyekszem több típusú problémát is bemutatni, majd a 
későbbiekben ezekre adok megoldási javaslatokat. 

Az első gond, ami felmerülhet az, ha nem használunk 
tranzakciókat. Tranzakciónak az olyan műveletsorozatot ért- 
jük, amelynek lefutása után vagy az összes művelet hatása ér- 
vényre jut, vagy egyiké sem. Köztes állapot nincs. Ez úgy is 
felfogható, hogy a műveleteket ,becsomagoljuk", és egyetlen 
(összetett) műveletként értelmezzük (Ha ajándékba viszünk 
egy pulóvert és egy pár zoknit valakinek, és azt egy papírba 
csomagoljuk, akkor már nem ajándékokról beszélünk általá- 
ban, hanem ajándékról. A többes szám akkor jut érvényre, ha 
a pulóvert és a zoknit külön csomagoljuk. Ugyanez igaz a 
tranzakciókra is.) 

Ha az adatbázist elérő műveleteinket nem tranzakcióként ke- 
zeljük, fennállhat a probléma, hogy inkonzisztencia lép fel. 
Nézzük például a következő esetet: Két felhasználó ugyanazt 
a táblát használja, írják-olvassák az adatokat. Tegyük fel, hogy 
az egyes felhasználók az alábbi műveletsort kívánják végre- 
hajtani: 


/t 1. felhasználó $/ 
ADDtoDB(Vezeteknev, "Kis") 
ADDTODB(Keresztnev, "Kató") 


/t 2. felhasználó §/ 
ADDTODB(Keresztnev, "Jenő") 
ADDTODB(Vezeteknev, "Nagy") 


Mit várnak a felhasználók az utasítássorozat lefutása után? 
Nyilván azt, hogy az 1. felhasználó kódjának köszönhetően az 
adatbázisba kerülnek egy ,Kis Kató" nevű hölgy adatai, a 2. 
felhasználó pedig egy , Nagy Jenő"-t szúr be. Ez így történik a 
valóságban is, ha a két felhasználó szigorúan egymás után fér 
az adatbázishoz. 

Ha azonban a hozzáférés párhuzamos, előfordulhat, hogy a 
felhasználók adatai rossz sorrendben kerülnek az adatbázisba: 
először az 1. felhasználó vezetékneve, majd a 2. keresztneve, 
végül a 2. vezetékneve és az 1. keresztneve kerül az adatbázis- 
ba. Ennek megfelelően az adatbázisban a következő két sze- 
mély fog szerepelni: ,Kis Jenő" és , Nagy Kató". Nem hiszem, 
hogy ez bárkinek is jó lenne... 





A SPIN CONTROL és a Promela 


A továbbiakban egy olyan modellező eszköz használatát mu- 
tatom be, amellyel a fenti probléma is jól kimutatható. Termé- 
szetesen a többi igazolására is ezt fogom használni. Az eszköz 
a Spin Control névre hallgat, és mind a Windowsos, mind a 
Unix-os verziója a [spinroot] címről tölthető le. (A címen rész- 
letes telepítési útmutató is található — nem triviális!) A Spinnek 
konzolos verziója is van, én azonban most a grafikusat muta- 
tom be. Elindítva egy, az alábbihoz hasonló felületet láthatunk: 
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File, SPIN DESIGN VERIFICATION Unettf7 Find 








tidefine busy 1 
ttdetine free 0 


orociype Usert() ( 


do 
atomic ( 
pn ÖtoDBÍVezeteknev. KirveT, 
Print TADOtODBÍVezeteknev. "KatorJw7. 





1 
ap, 
od 
) 


örociype User2) ( 
do 
atomic ( 


Prirtl( TADDLODBIVezeteknev, "Jeno NI 
Drintl( "ADOtODEfVezeteknev, "Nagy Wv1. 


od 





AZAZ e ee aze e za] 








EG A Spin Control felhasználói felülete 


Mint az az ábráról is látszik, nem egy grafikus , tili-toli" eszköz- 
ről van szó. Valószínűleg sokan vannak, akik örömmel üdvöz- 
lik ezt a tényt, de bizonyára olyanok is akadnak szép számmal, 
akik nem fogják szeretni. 








A SPIN elosztott rendszerek formális verifikációjára alkalmas 
szoftver rendszer, melyet a Bell Labs fejlesztett ki. Célja, hogy 
hatékony verifikációs lehetőséget adjon különböző szoftver- 
rendszerek (nem hardver!) számára. A program egy magas- 
szintű nyelvet, a Promelat (Process Meta Language) használja 
a verifikálandó rendszer specifikálására. 

A SPIN fő alkalmazási területe elosztott rendszerek logikai ter- 


vezési hibáinak detektálása, így például operációs rendszerek, 


konkurens algoritmusok, adatkommunikációs proto- 
kollok stb. ellenőrzése. 


uld 


sa 


tj 


A SPIN bemeneti nyelve a Promela, amely lehetősé- 

get ad arra, hogy absztrakt módon megfogalmazzunk 

egy elosztott rendszert csak a lényegre figyelve, vagyis a 
processzinterakció szempontjából irreleváns részleteket ki- 
hagyva. 

A Promela egy C-szerű nyelv, kibővítve a kommunikáció és a 
nemdeterminizmus lehetőségével, és véleményem szerint igen 
könnyen elsajátítható (ha valaki már kellő gyakorlattal rendel- 
kezik egyéb programnyelvek terén 0). Egy Promela program 
segítségével — mely processzekből, üzenetcsatornákból és vál- 
tozókból épül fel —, alkalmazásunk viselkedésének modelljét 
építjük fel. A processzek globális objektumok, és ezek szolgál- 
nak a modellezni kívánt rendszer viselkedésének specifikálásá- 
ra. A csatornák kommunikációra szolgálnak, és lehetnek glo- 
bálisak, illetve processzen belül lokálisak is. Ugyanígy a válto- 
zók is lehetnek globálisak, illetve processzen belül lokálisak. 
Míg a processzek specifikálják a viselkedést, a csatornák és 
globális változók definiálják azt a környezetet, amely a 
processzek futásához szükséges. 

A Promela alap-adattípusai a következők: bit, — bool, 
byte, int (32 bit, előjeles), short (16 bit, előjeles), chan. 
Úgy gondolom, az első öt magától értetődő, egyedül a chan le- 
het szokatlan. Segítségével kommunikációs csatornát tudunk 
definiálni az alábbi módon: meg kell adni a csatorna hosszát 
és a rajta szállítandó adatok típusát. Például: 


chan myFirstChan - [7] of (int) 


Ez egy 7 hosszú csatorna, amelyben minden üzenet egy int ér- 
téket jelent. Ha szinkron, azaz puffer nélküli csatornát szeret- 
nénk létrehozni, annak módja a következő: 


chan mySyncChan - [0] of (bit) 


Ebben az esetben tehát a csatorna hosszának 0-t kell megadni. 


Egy változó vagy csatorna állapotát csak egy processzen belül 
változtathatjuk, illetve figyelhetjük meg. Process viselkedését 
proctype deklarációval definiálhatjuk a következő módon: 
proctype procname (formal parameters) ( 


local declarations; statements 
: ő 


A pontosvessző a kijelentések közti szeparátor (nem kijelentés 
befejezésére utaló jel, mint például a C-ben, ezért nincs szük- 
ség pontosvesszőre az utolsó kijelentés után). A PROMELA két- 
féle kijelentés-szeparátort ismer: a pontosvesszőt: ";", és a nyi- 
lat: " -5 ". Ez a két szeparátor ekvivalens. A nyíl szeparátort 
gyakran használják arra, hogy informális módon jelöljék az 
okozati összefüggést két kijelentés között. 

A proctype definíció csak a processz viselkedését deklarálja, 
végrehajtásra nem alkalmas. Kezdetben a Promela modellben 
csak egy processz hajtódik végre: ez az init processz, ezt exp- 
licit deklarálni kell minden Promela specifikációban. Ezek 
alapján a legkisebb PROMELA specifikáció: 


init ( skip ) 


A skip az az utasítás, ami nem csinál semmit. A kezdő 
processz tud globális változókat inicializálni, és processzeket 
példányosítani. A processz példányosításra szolgál a run uta- 
sítás: 
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init ( run A() ) 


— 


et. A run utasítással ei rocessztípusból akárhán 
Sz u j Sy P SzlB y 
eg processzt létrehozhatunk. Ily módon nagyon egysze- 
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rűen modellezhetők a konkurens folyamatok, hiszen 
a processzek végrehajtása nemdeterminisztikus. 
Vagyis ha adott az alábbi init processz: 


init ( run A(); run B() ) 


Mind az A, mind a B processz elindul, és mindaddig futnak 
párhuzamosan, amíg működésük be nem fejeződik. 


Ily módon az előbb felvázolt alkalmazásunk Promela- 
modellje, ha a két felhasználó egymás után akarja beírni az 
adatokat az adatbázisba: 

proctype User1() ( 


printf ( "ADDTODB(Vezeteknev, 
printf ( "ADDTODB(Keresztnev, 


"Kis")Wa"); 
"Kato")n"); 
§ 


proctype User2() ( 
printf ( "ADDTODB(Keresztnev, 
printf ( "ADDTODB(Vezeteknev, 


"Jeno") a"); 
"Nagy" )Ma"); 


1 
Amttjet 
run User1(); 
run User2(); 
) 


A User processzekben most mindössze annyi történik, hogy a 
képernyőre kiírjuk az ADDTODB utasítást, ezzel modellezzük 
annak megtörténtét. Jól látható, hogy ha csak egy-egy felhasz- 
náló folyamatát tekintjük, az utasítások szép sorban hajtódnak 
végre, az adatbázisba tehát azok az adatok kerülnek, amelye- 
ket mi szeretnénk. 

A Spin Control segítségével ellenőrizhetjük is modellünket. A 
szimuláció futtatása előtt be kell állítani annak paramétereit 
(Run... 2 Set Simulation Parameters...). Többnyire az alap- 
beállítások jók lesznek, azonban ezek tetszés szerint módosít- 
hatók. A szimuláció indításakor (Start) a következő ablak jön 
fel (néhány másikkal együtt: 





7 Simulation Output Si 
mm 0 proc - (root) ereates proc. 0 (init:) 
1 proc 0 (iinit:) creates proc 1 
1 proc 0 (init) ine. 17 "pan. in" 


-lOl21 





] 
te 1) [run User) 


isi 


Single Step] Run 





Saveint [/simout 














Clear] Cancel 











B A szimuláció kimenete 


Ennek segítségével vezérelhetjük a szimulációt: lépésenként 
haladhatunk (Single Step), elindíthatjuk a rendszert folyamatos 
működésre (Run), elmenthetjük az aktuális ablaktartalmat, tö- 
rölhetjük azt, illetve kiléphetünk a szimulációból. 
Végigfuttatva a programot, az alábbi kimenetet kapjuk: 


0: proc - (:root:) creates proc 0 (:init:) 
1: proc 0 (:init:) creates proc 1 (User1) 
zÚsS proc 0 (:init:) line 13 "pan in" 
$ (state 1) [(run User1())] 
ADDTODB(Vezeteknev, "Kis") 
2 proc 1 (User1) line 2 "pan in" 


W (state 1) 
$ [printf("ADDTODB(Vezeteknev, 
B sKis")Nin")1 


je proc 0 (:init:) creates proc 2 (User2) 
31s MONOG HENDON ZEN ELMENTÉL Npanétn 
$ (state 2) I(run User2())1 
ADDTODB(Vezeteknev, "Kato") 
4z proc 1 (User1) line A] 
$ (state 2) 
$  IPrintf(ADDTODB(Vezeteknev, 
$ :"Kator)Wn!")] 
ADDTODB(Vezeteknev, "Jeno") 
5z proc 2 (User2) line A 
$ (state 1) 
4 [printf("ADDTODB(Vezeteknev, 
$ :"Jeno")Wn!)] 
ADDTODB(Vezeteknev, "Nagy") 
6: proc 2 (User2) line 8 
$ (state 2) 
4 [printf("ADDTODB(Vezeteknev, 
$ "Nagy")Wn")1 


"pan in" 


"pan in" 


"pan in" 





proc 2 (User2) terminates 
proc 1 (User1) terminates 
6: proc 0 (:init:) terminates 


3 processes created 


Ebből jól látható a program futásának minden lépése: a végre- 
hajtott utasítások sorozata, illetve az általunk kiadott üzenetek, 
amelyek az ADDTODB utasításokat tartalmazzák. Az adatok a 
kívánt sorrendben kerülnek az adatbázisba. 


Mi van azonban akkor, ha a felhasználók több adatot is fel 
akarnak egyszerre tölteni, és előre nem tudjuk, milyen mennyi- 
séget, és azt sem, milyen időközönként jön újabb üzenet? Az 
adatok egyre érkeznek és érkeznek az adatbázishoz, és az már 
azt sem tudja, mit hova kell tennie, és máris itt a káosz: az 
adatbázisba nem a megfelelő adatok kerülnek! 

Lássuk az ide tartozó Promela-kódot: 


proctype User1() ( 
do 
:: printf("ADDTODB(Vezeteknev, 
printf ( "ADDTODB(Vezeteknev, 
:: skip; 
od 
) 


"Kis")Wa"); 
"Kato") mm"); 


proctype User2() ( 
do 
:: printf("ADDTODB(Vezeteknev, 
printf ( "ADDTODB(Vezeteknev, 


"Jeno" ) a"); 
"Nagy" )Wa") ; 


:: skip; 
od . 
) 
FRETT 
run User1(); 
run User2(); 
Ni 


Mint az látható, nem sokat változott, mindössze két új utasítást 


skip parancsot. A do...od végtelen ciklust jelent, ám annak 
speciális változatát: minden egyes dupla kettőspont (::) egy le- 
hetséges végrehajtási útvonalat jelöl. A négyespont után felté- 
teleket is adhatunk meg, így arra az ágra csak akkor fut rá a ve- 
zérlés, ha a feltétel teljesül. Ennek megfelelően lesznek igaz és 
hamis ágak, ezek közül teljesen nemdeterminisztikusan választ 
egyet, amelyet végrehajt (tehát az ágak sorrendje nem befolyá- 
solja a végrehajtást!!). Ezután újra és újra végrehajtódik a cik- 
lus magja. Futása a break utasítással szakítható meg. 

A fenti kódban látható skip a Promela üres utasítása. Nem csi- 
nál semmit. Számunkra most remekül megfelel annak model- 
lezésére, hogy a felhasználó éppen nem küld adatot az adatbá- 
zisba. 





Így a fentiek értelmében a felhasználói processzek egy végte- 
len ciklusban vannak, és minden egyes iteráció alkalmával 
vagy küldenek adatot az adatbázisba, vagy nem. 

Sejthető azonban, hogy valami csalafintaság van a dologban. 
Mivel a Promela utasítások végrehajtása nemdeterminisztikus, 
és a két processz egymással párhuzamosan fut, semmi nem ga- 
rantálja az adatok feltöltésének sorrendjét. Lássuk a szimuláció 
kimenetének egy részletét: 


ADDTODB(Vezeteknev, "Kis") 

3752 proc 1 (User1) line 2-"pan dna 
$ (state 4) 
4 [printf("ADDTODB(Vezeteknev, 
9 "Kis")WWn")1 

ADDTODB(Vezeteknev, "Kato") 

38: proc 1 (User1) line 4 "pan in" 
$ (state 2) 
4  [printf("ADDTODB(Vezeteknev, 
B "Kato")Wn!)1 

39: proc 2 (User2) line 15 "pan in" 
4 (state 5) [.(goto)1] 

40: proc 1 (User1) line mi" panédinn 
B (state 5) [.(goto)] 

41: proc 2 (User2) line 10 "pan in" 


W (state 4) [(1)1 

42: proc 1 (User1) line 2. spancin 
4 (state 4) [(1)1 

43: proc 1 (User1) line 7. Spantán" 


$ (state 5) [.(goto)] 

44: proc 2 (User2) line 15 "pan in" 
$ (state 5) [.(goto)] 

45: proc 2 (User2) line 10 épancir 


4 (state 4) [(1)1 
46: proc 1 (User1) line 2" "pan in" 
$ (state 4) [(1)1 


47: proc 2 (User2) line 15 "pan in" 
4 (state 5) [.(goto)] 
ADDTODB(Vezeteknev, "dJeno") 
48: proc 2 (User2) line 10 "pan in" 
$ (state 4) 
4 [printf("ADDTODB(Vezeteknev, 
b "Jeno")Wn")] 
ADDTODB(Vezeteknev, "Nagy") 
49: proc 2 (User2) line 12 "pan in" 
$ (state 2) 
4 [printf("ADDTODB(Vezeteknev, 
3 "Nagy")Wn!)] 
50: proc 2 (User2) line 15 "pan in" 
$ (state 5) [. (goto) ] 
51 proc 2 (User2) line 10 "pan in" 
W (state 4) [(1)1 
52is proc 2 (User2) line 15 "pan in" 
W (state 5) [.(goto)1 
ADDTODB(Vezeteknev, "Jeno") 
537 proc 2 (User2) line 10 "pan in" 
b (state 4) 
$ [printf("ADDTODB(Vezeteknev, 
$ :"Jenot)Wnt)] 
54: proc 1 (User1) line 7 "pan in" 
W (state 5) [.(goto)] 
ADDTODB(Vezeteknev, "Kis") 
5B5iz proc 1 (User1) line 2.."pansin" 
$ (state 4) 
§  Iprintf(ADDTODB(Vezeteknev, 
9 "Kis")WWn")1 


Mit olvashatunk le a fenti szimulációból? Az első néhány sor- 
ban egyeznek az adatok, párosával jönnek a vezeték- és ke- 
resztnevek: Kis Kató, Nagy Jenő. Közben helyenként a felhasz- 
nálók valóban várakoznak, ezt jelzi a sok kimenet nélküli, üres 
sor (érdemes kipróbálni a skip utasítás nélkül is végigfuttatni a 
szimulációt, akkor egyrészt jól láthatóvá válik, hogy hol van- 
nak holtidők; másrészt mivel akkor folyamatosan töltik fel az 
adatokat a felhasználók, sokkal több érvénytelen adat lesz, hi- 
szen az az esély sincs meg, hogy egyikük épp várakozik, amíg 
a másik dolgozik). A szimuláció végén azonban olyan informá- 


ció kerül az adatbázisba, amit egyik felhasználó sem akart, 
csupán adataik összekeveredésével jött létre: 


ADDTODB(Vezeteknev, "Jeno") 
53 proc 2 (User2) line 10 "pan in" 
b (state 4) 
4 [printf("ADDTODB(Vezeteknev, 
$ :"Jenor)Wn")] 
54: proc 1 (User1) line 7" span dán" 
$ (state 5) [. (goto)] 
ADDTODB(Vezeteknev, "Kis") 
a proc 1 (User1) line 2/rpanyirir 
4 (state 4) 
4 [printf("ADDTODB(Vezeteknev, 
6 "Ris")Mn")] 


Az adatbázisba tehát Kis Jenő kerül, holott az eredeti adataink 
között ilyen nem szerepelt! 


Hogyan valósítható meg, hogy a fenti probléma ne fordulhas- 
son elő? Egy lehetséges megoldás, hogy az adatbázis-elérése- 
ket tranzakciók formájában valósítjuk meg, vagyis a felhaszná- 
lók ADDTODB utasításait ,becsomagoljuk". A Promelában ez 
az atomic utasítással valósítható meg, az alábbi módon: 


proctype User1() ( 
do 
:: atomic ( 
printf("ADDTODB(Vezeteknev, "Kis")in"); 
printf("ADDTODB(Vezeteknev, "Kato")Mn"); 
) 
:: skip; 
od 


Hasonlóan kiegészítve a másik felhasználói processzt is, bizto- 
sítható, hogy a felhasználói adatok ne keveredjenek össze a 
fent látott módon. A szimuláció lefuttatásától és bemutatásától 
most eltekintek. Aki nem hiszi, járjon utána. 


Holtponthelyzetek 


A fenti megoldás máris nagyobb hatékonyságot eredményez 
mint az előző, minden külső körülményt figyelmen kívül ha- 
gyó változat. Azonban egy igen lényeges dolgot itt is figyelmen 
kívül hagytunk: az adatfeltöltést egyszerűen egy kiíratással szi- 
muláltuk, holott ez a művelet erőforrást igényel az adatbázis- 
tól. Arra az időre, amíg írjuk az adatokat, szükségszerűen fog- 
laljuk ezen erőforrásokat, tehát mások számára nem hozzáfér- 





hetők. A fenti példánál maradva, ügyfelünk nevének felvitelé- 
nél mind a vezeték-, mind a keresztneve mások számára elér- 
hetetlen mindaddig, amíg mi írjuk. Ha egy személy adatait 
egységként szeretnénk kezelni, adatainak írásakor elengedhe- 
tetlen, hogy mindkét mezőt egyszerre zár alatt tartsa. 
Hozzunk tehát létre két erőforrást, amely a két név mezőt rep- 
rezentálja. Ezek foglalása úgy történik, hogy egy-egy központi 
processz figyeli az erőforrás állapotát, és kölcsönös kizárással 
biztosítja, hogy egyszerre csak egy felhasználó foglalhassa azt. 
A kölcsönös kizárás megvalósítása az alábbi módon történik: 


chan vezeteknev - [0] of (bit); 
chan keresztnev - [0] of (bít)l; 


tdefine busy 1 
tdefine free 0 


proctype Resource1l() ( 
byte count - 1; 


do 
1: (count -- 1) -5 


ásazalla pon sargtasizegi ep / 
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vezeteknev!busy; count - 0; 
0) -s 
vezeteknev?free; count - 17 
od ék 
) E 





proctype Resource2() ( 
byte count - 1; 


do. 
:: (count -— 1) -5. 
keresztnev!busy; count - 0; 
:: (count -—— 0) -5 A 
keresztnev?free; count - 1; 
od 


A fenti kód a Disjkstra algoritmus megvalósítása. Alapelve a 
következő: a count változóban tároljuk azt, hogy még hány 
felhasználó foglalhatja le aktuálisan az adott erőforrást. Értéke 
1, ha az erőforrás szabad, azaz még egy felhasználó , elfér", 0 
pedig akkor, ha már foglalt az erőforrás, azaz jelenleg senki 
nem fér hozzá. Ha a count értéke 1, lefoglalhatjuk az adott 
erőforrást (vezeteknev! busy ) , majd a count-ot 0-ra állít- 
juk. A felszabadításért természetesen az aktuálisan foglaló fel- 
használó felelős, hiszen csakis ő tudhatja, mikor végzett az 
adatátvitellel. 

A fenti kódrészletben jól látható, hogy az erőforrások foglalása 
és felszabadítása üzenetváltásokkal történik. Az erőforrás a sa- 
ját csatornájára busy üzenetet küld, ha indulhat a versengés 
érte, tehát valamely felhasználó lefoglalhatja. A felhasználónak 
pedig az adott erőforrás csatornájára kell free üzenetet kül- 
denie, ha végzett az adatfeltöltéssel. 


Ennek megfelelően a módosított felhasználói processzek: 


proctype User1() ( 


do 
:: atomic ( 
vezeteknev?busy -5 
W"tprintf("ADDTODB(Vezeteknev, "Kis")Wn"); 
keresztnev?busy -5 
Wtprintf("ADDTODB(Keresztnev, "Kato")Wn"); 
vezeteknev!free; 
keresztnev!free; 
, 
:: skip; 
od 
) 


proctype User2() ( 
do 
Sdatontcát 
keresztnev?busy -5 
printf("ADDTODB(Keresztnev, !"Jeno")Wn"); 
vezeteknev?busy -5 
printf("ADDTODB(Vezeteknev, "Nagy")Wn"); 
keresztnev!free; 
vezeteknev! free; 


di 
:: skip; 
od 

d 

ANLEKG 
run Resourcel(); run Resource2(); 7 
run User1(); run User2(); 

, 


Mi történik most? Amikor a felhasználó írni akar, lefoglalja a 
szükséges adatmezőket, szigorúan csak akkor, amikor szüksé- 
ge van rá. Felszabadítani viszont csak akkor tudja, ha már 
minden adatot felvitt, hiszen csak így biztosítható, hogy az ál- 


tala felvitt vezetéknévhez az oda illő keresztnév kerüljön. Ez 
azonban újabb problémákat okozhat... 

Tegyük fel ugyanis, hogy a felhasználók a fenti sorrendben fog- 
lalják le az erőforrásokat: vagyis az 1. felhasználó először a ve- 
zeték- majd a keresztnevet, a 2. pedig fordítva. Ezzel mindad- 
dig nincs is semmi gond, amíg olyan helyzet nem áll elő, ami- 
kor az 1. felhasználó már lefoglalta a vezetéknevet, a 2. a ke- 
resztnevet, és épp mindketten írni szeretnék a másik adatot. Az 
1. felhasználó ekkor várakozni kezd a keresztnévre, a 2. pedig 
a vezetéknévre. Egymásra várakoznak, ezáltal a végrehajtás 
blokkolódik. Ez a jelenség a holtpont (deadlock). 


Lássuk a program futását! Az előzőekhez hasonlóan indítsuk el 
a szimulációt, majd nézzük meg a programhoz tartozó szek- 
venciadiagramot (Message Seguence Chart). 

Mit láthatunk a fenti ábrán? Az öt szál az öt processzt szemlél- 
teti, sorrendben: init, Resourcel (vezetéknév), 
ce2 (keresztnév), User1, User2. Az üzenetváltások 
piros nyilak formájában jelennek meg: a nyíl az üzenet irányá- 
ba mutat, felirata az üzenet tartalma. A legfelső piros nyíl pél- 
dául azt jelenti, hogy a Resource1 küld üzenetet a User1- 
nek, vagyis a vezetéknév erőforrást az 1. felhasználó foglalja 
innen kezdve egészen addig, amíg ellentétes irányú, felszaba- 
dító üzenetet nem detektálunk. 
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Az erőforrások zárolásának következménye: holtpont 


Lássuk tehát a fenti történéseket! Az első felhasználó lefoglalja 
a vezetéknevet, majd a keresztnevet, majd miután végzett az 
adatfeltöltéssel, fel is szabadítja őket. Ezután a 2. felhasználó 
kapja meg a keresztnév, majd a vezetéknév használati jogát, s 
miután végzett az írással, feloldja a zárat rajtuk. 

Ezek után kezdődik az igazán izgalmas rész (lásd kiemelé: 
1-es felhasználó lefoglalja a vezetéknevet, a 2-es pedig a ke- 
resztnevet. Ezután elkezdődik a véget nem érő várakozás, ami 
holtponthelyzetet okoz a rendszerben. 

Természetesen a holtpont elkerülésére is léteznek használható 
technikák. Egyik jó módszer lehet, ha a fenti két technikát öt- 
vözzük, vagyis kölcsönös kizárással biztosítjuk, hogy erőforrá- 
sainkhoz egyszerre csak egy felhasználó férhessen hozzá, de a 
felhasználók hozzáférését egyetlen egységként, tranzakcióként 
kezeljük. Nem külön-külön tekintjük tehát erőforrásnak a két 
adatmezőt, hanem egy egységként végezzük a hozzáférést. 





Lássuk, hogyan néz ki ez a gyakorlatban: 





Jól látható, hogy itt már csak egyetlen erőforrást, a Resource-t 
definiáljuk, ez felelő a teljes név (vezetéknév -- keresztnév) 
erőforrásként történő kezeléséért. Erre az erőforrásra biztosí- 
tunk kölcsönös kizárást, az előbbiekhez hasonló módon. 

A felhasználók így ezt az erőforrást vizsgálják, és ha elérhető 
számukra, lefoglalják, és elkezdik az adatforgalmazást. 
Természetesen az is megoldható lenne, hogy a token ne csu- 
pán egy adatfeltöltés erejéig legyen az adott felhasználónál. Ha 
azt akarjuk modellezni, hogy előre meg nem határozható ideig 
forgalmaz adatokat, egyszerűen a fenti ADDTODB műveletek 
helyére egy belső ciklust kell tenni, valahogy így: 
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Lássuk, ezen bővítés hatására hogyan viselkedik a l 
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E Holtpont elkerülése 


Most szándékosan másik beállítását használtam a szekvencia- 
diagramnak: az előző példában a mezők feliratai a megfelelő 
üzenetek voltak, most azonban sokkal beszédesebb, ha a lépé- 
sek sorszámát látjuk. (A beállítás a Set Simulation Parameters... 
menüpont alatt érhető el.) 

Jól látható, hogy az üzenetváltás folyamatos, mindaddig fut a 
program, amíg működését kívülről meg nem szakítjuk. A me- 
zőkben lévő számokból pedig arra következtethetünk, hogy 
mennyi ideig birtokolta az adott felhasználó a tokent. (Ez a szi- 
muláció kimenetén is nyomon követhető, ha az adatfeltöltést 
jelző ADDTODB-ket nyomon követjük.) 


Még egy utolsó gondolat. Adatbázis-alkalmazások tervezésé- 
nél rendkívül fontos a skálázhatóság szem előtt tartása. A fenti 
modell esetén alkalmazásunk jól skálázható, hiszen újabb fel- 
használó felvétele csupán egy újabb User processz indítását je- 
lenti. Ha a felhasználók viselkedése azonosnak tekinthető (pél- 
dául megfelelő nemdeterminizmus bevitelével a felhasználó 
belső modelljébe), elég egyetlen felhasználói processz létreho- 
zása is, és az inicializáláskor azt indíthatjuk több példányban. 


A lehetőségek végtelenek, innen kezdve már csak fantáziánk 
szab határokat annak, hogy milyen célokra és hogyan használ- 
juk ezeket a módszereket. 

Néhány ötlettel még én is előállok a következőkben, azonban 
ez már legyen a jövő hónap témája. 


Molnár Ágnes 
agiCharpia.homeip.net 
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." MP3-előadások az informatika nagyjaitól / 


Hudin-tanulás 
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Hudio-tanulás 


MP3-előadások az informatika nagyjaitól 


A történet úgy kezdődött, hogy át szerettem volna vinni egy BOOT.INI fájlt egyik gépről a másikra. 
Flopilemezen. Ez sajnos a mai flopik minősége miatt kudarcba fulladt, hát arra gondoltam, veszek egy 
USB-adathordozót. De okos ember ma már nem vesz egyfunkciós USB-eszközt, legyen hát MP3 lejátszó! 


Amint kezembe került az eszköz, elkezdtem MP3 fájlok után 
kutatni a weben (szomorúan konstatáltam, hogy a Napster- 
korszakot másfél évvel lekéstem). Azután eszembe jutottak a 
Microsoft öntanító CD-i, amiket olyan lelkesen küldözgetnek 
nekem a tech.net CD-sorozat részeként (a CD-változat nem ke- 
verendő össze az újsággal!), de soha egyetlen egyet még meg 
nem néztem. 

Nem mintha nem érdekelne, de amikor számítógép előtt ülök, 
akkor dolgozom. Ha meg nem dolgozom, teljes mértékben tar- 
tózkodom az informatika áldásaitól. Így aztán szak-CD néze- 
getésére ,sosincs lehetőségem". Ellenben felfedeztem, hogy 
naponta mintegy kétórányi holt időm van: munkába menet és 
jövet. Nosza, töltsük le a kis kütyüre az előadások hangját! Ezt 
az elképzelést gyorsan feladtam: órákig tartó konverzióval kel- 
lett volna előállítanom a megfelelő felbontású MP3 hanganya- 
got. Valahol biztosan meg kell lenniük letölthető formában! 
Keressünk ismét a weben! Keresőszavak: MP3, technet. Találat: 
http://technetcast.ddj.com. Na nézzük, mit is találtunk? Mit 
adott kezünkbe a vak véletlen? 


Dr. Dobbs Journal 


Ez a cím a programozók által ismert, és méltán elismert Dr. 
Dobbs magazin webjére mutat. Valóban találunk itt letölthető 
MP3-előadásokat, de micsoda meglepetés: az IT-iparág veze- 
tőinek, látnokainak és guruinak előadásait! Íme néhány név az 
előadók listájából: Donald Knuth, Bill Gates, Linus Torvalds, 
Michael Dell, az ex-Borlandos Philippe Kahn, A SOAP atyja: 
Don Box, az IT iparág fejlődését leíró Moore-törvény felállító- 
ja: Gordon Moore és még sokan mások. 

Ennél is érdekesebb a tematikus választék. Ezt egyszerűen ide- 
másolom: ai, business, c-4--4, computer history, cyberlaw, 
cyberrights, dot-net, graphics, gamedev, java, languages, linux, 
mac os, networking, open source, os design, perl, peer-to-peer, 
programming, robotics, security, software development, web 
services, www, xml, programs, codebytes, recurse. 

Egy-két jó előadás 

Elsőként a főlapon kiemelt előadások közül hallgattam meg jó 
néhányat. Richard Rashid a Microsoft Research vezetője pél- 
dául az operációs rendszerek következő nemzedékének várha- 
tó képességeiről beszél a ,Rethinking the Modern OS" című 
előadásában. El tudunk képzelni egy olyan oprendszert, ami 
ugyanúgy tanul a vele való kommunikáció során, mint egy tit- 
kárnő? Megfigyeli, hogy mit hogyan csinálunk, és legközelebb 
már maga is tudja. Íme néhány nem triviális példa: 

A A naptáramba rendszeres eseményként, tehát minden 
szerda délután 5-re fel van véve mondjuk az, hogy ,te- 
nisz öcsivel". Ezeken a napokon én négy óra 7 perckor 
ki szoktam jelentkezni a gépből. Mi következik ebből? 


Hogy ez egy távoli helyszínen lévő esemény, amihez 1 
óra odaút szükségeltetik. Mit tesz egy okos titkárnő 
és/vagy gép? Először is figyelmeztet, ha netalán fél ötre 
készülnék új bejegyzést készíteni, hogy ez nem feltét- 
lenül jó ötlet. Másodszor, szerda délutánonként min- 
den mondandóját (riasztások, feladatok stb.) négy óra 
előttre időzíti, mert utána már hiába kiabál! 

A Gondoltak-e arra, hogy egy olyan szövegszerkesztő, 
amelyik pirossal aláhúzza a helyesírási hibát, zölddel 
pedig a többi nyelvtani tévedést, igen közel áll a szö- 
veg megértéséhez? Nyelvtani elemzésre, a szavak rago- 
zatlan alakjának megtalálására már képes, már , csak" 
az értelmezés van hátra. De készül. A jövő oprend- 
szerei és irodai alkalmazásai érteni fogják a mindenna- 
pos irodai kommunikációt, és tanulnak majd leveleink- 
ből, dokumentumainkból! (Én csak azért izgulok, hogy 
mindez opcionális legyen...) 


Ezt követően egy olyan előadást töltöttem le és hallgattam 
meg, melyben a Google rendszergazdai csapatának vezetője 
értekezik a skálázás lehetőségeiről. Tőle aztán van mit tanulni! 
Fő céljuk, hogy minden Google-keresés fél másodpercnél rövi- 
debb idő alatt lefusson még abban az esetben is, ha a gépek je- 
lentős része kiesik (mondjuk leszakad a netről a fél USA). Eh- 
hez hatezer (6000!) gépből álló szerverfarmot használnak. 
Ekkora gépmennyiség esetén már igencsak számít a felhasznált 
alkatrészek MTBF-je (Mean Time Between Failures), áltagos 
fejreállási ideje. Nos, a Google egymagában eltart egy igen je- 
lentős forgalmú hardverbeszállítót: naponta mintegy 60 számí- 
tógépükben , pukkan el" ez-az. Ilyenkor a teljes gépet kicserélik. 
Természetesen az óriási teljesítményhez igen feszes szoftver- 
rend is tartozik: egyik gépen sincs semmilyen felesleges kom- 
ponens. 

Harmadikként a Denial of Service támadás forrásának felkuta- 
tásáról szóló előadást hallgattam meg. Mi a DoS? Sok esetben 
nem más, mint a szerverek sávszélességét tökéletesen felzabá- 
ló rosszindulatú adatfolyam. Mivel a kéretlenül beérkező IP- 
csomagok forrását tudományosan megállapítani nem lehet, 
nem marad más, mint a teljes Internet ágankénti lezárása. Ho- 
gyan vesznek rá a nyomozók mondjuk egy magyar szolgálta- 
tót, hogy egyik routerét kapcsolja ki? Sehogy. Odaküldenek 
egy DoS-támadást, ami néhány percre megfojtja az adott 
routert. Kutyaharapást szőrivel! 


Fóti Marcell 

marcellfönetacademia.net 
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2 ACADEMIA 


Objektumorientált Analízis, Tervezés 
8. Design Patterns 


3 napos tanfolyam fejlesztőknek 


A tanfolyamon minden OOP tervezési tudást, tapasztalatot és szemléletmódot átadunk 
hallgatóinknak, akik a laborokon megszerzett gyakorlat és a kész forráskódok birtoká- 
ban már közvetlenül a tanfolyam után bevethetik a Design Patternekben rejtőző tudást. 


Ajándék könyv a tanfolyam résztvevőinek 


Design Patterns 


Elements of Reusable 
Object-Orient 
Erich Gamma 
Richard Helm 
Ralph Jóhnson 
John Vlissides 






1!  Foreword by Grady Booch 
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Kell-e nekem objektumorientált tervezés? 
Ha C-ot, VB.NET-et, JScript.NET-et, JAVA-t, C-----t, Delphit vagy egyéb 
objektumorientált nyelvet használ, a válasz: igen. Egyébként nem. 


. Kell-e nekem Design Patterns? 
Ha könnyen módosítható, karbantartható, bővíthető, világosan átgondolt prog- 
ramterveket és kódokat akar írni, akkor igen!" 


Kell-e nekem Iterative Development? 
Csak akkor, ha nyugodtan akar aludni, nem félve attól, hogy az ügyfele holnap 
már más követelményekkel áll elő, amihez Önnek alkalmazkodni kell." 


En programozó vagyok, nem tervező! 
A tervezés sokszor nem válik el élesen a kódírástól. Legtöbbször programozás 
közben is terveznünk kell. §7" 


Vágjuk bele! Mi kell hozzá? 


Az OOPA/D (Objektumorientált analízis és tervezés) egy izgalmas és nagyon 
szerteágazó tudományág. A NetAcademia bemutatja Önnek, milyen mód- 
szerekkel lehet becserkészni az ismereteket, így hónapokat spórolhat meg ta- 
nulási idejéből, és három nap múlva teljesen más szemmel fog nézni az OOP- 
re (és az ügyfeleire is)! 


Legyen az elsők közt! 


ACADEMIA 


x Persze ez DP nélkül is lehetséges. Úgy 10 év programtervezési gyakorlattal. 


xx Teljesen biztos lehet benne, hogy ügyfele meggondolja magát. Ez ellen nem harcolni kell, hanem felkészül- 


ni rá. 
tr Ha arra gondol, hogy Ön kódokat ír és nem dobozokat tologat, akkor jó helyen kopogtat! 


Objektumorientált Analízis, Tervezés 8. Design Patterns 


Átfogó tudás a Design Pattern-alapú tervezésről 


Előadó: 
Soczó Zsolt, MCSD, MCAD, MCDBA, MCT - NetAcademia 





Témakörök: A programozási módszertanok szerepe. Az Iterative Development alapjai és 
fázisai. Hogyan kezeljük a változást? Az objektumorientált analízis alapjai és eszközei: Use 
Case modell, Domain modell, GRASP analízis. A Patternek szerepe. Hogyan válasszuk ki a 
megfelelő DP-t? Milyen elvekre épülnek a DP-k? Két DP (Bridge és Strategy) levezetése. 
Refactoringok alkalmazása a kód átszervezésére. 

GoF" DP-k működése és gyakorlati alkalmazása .NET alkalmazásokban: Abstract Factory, 
Factory Method, Singleton, Adapter, Composite, Decorator, Facade, Command, Iterator, 
Observer, Template Method, Visitor. 

A DP alkalmazásának speciális esetei .NET-es környezetben. DP-k a .NET Frameworkben. 


Előkövetelmények: a tanfolyamhoz mindenképpen szükséges az OOP alapok és a Cs, JAVA 
vagy Ct-- alapfokú ismerete. A laborokhoz ASRNET és ADO.NET ismeretek előnyösek. A 
hátlapon található tanfolyamok segíthetnek a felkészülésben. 


Ajándék! Az egyedi, NetAcademia fejlesztésű tanfolyami jegyzet mellé hallgatóink a GoF 
Design Pattern című könyvét, valamint a tanfolyamon fejlesztett  webalkalmazás forráskódját 
kapják ajándékba. 


4 példakódok az összes 


tárgyalt DP gyakorlati 
alkalmazásával 


A tanfolyam kezdete őst Bővebb információ Ár [Ft] 


GoF": Design Patterns 
könyv 





2003. június 11-13. http://www.netacademia.net/whorkshop/DP 
2003. augusztus 27-29. Telefon: (1) 472-1214 


160.000 





Jelentkezés weben: http://www.netacademia.net/workshop/dp 
Jelentkezés faxon (472-1215) az alábbi adatok megadásával: 
cégnév, hallgató(k) neve(i), számlázási cím, e-mail, fax, telefon, időpont. 


: GoF — Gang of Four, a négyek bandája. Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides, a 
Design Patterns, Elements of Reusable Object-Oriented Software című könyv szerzőinek szleng elnevezése. 


További tanfolyamaink: 


2124 - Programozás C$ nyelven 
Bevezetés az Objektumorientált prog- 
ramozási elvekbe és elmélyülés a Cs 
nyelvben. Nagyon hasznos és alapvető tan- 
folyam, különösen azoknak, akik még nem 
ismerik az OOP-t (pl. VB6 programozók). 


2310 -  ASP.NET  webalkalmazások 
fejlesztése a Visual Studio .NET segít- 
ségével 

ASPNET alkalmazások fejlesztésének 


eszközei és technológiái. Praktikus, gyakor- 
latias, nagyon színvonalas tanfolyam modern 
webalkalmazások írásához. 


2349/2415 - A .NET keretrendszer prog- 
ramozása Cs/VB.NET nyelven 

.NET Framework alapozótanfolyam, a 
legalapvetőbb az összes között. Minden 
fontos ismeret benne van, ami a gyakorlati 
.NET programozáshoz elengedhetetlen, a 
fájlkezeléstől a hálózati programozáson át a 
többszálú alkalmazások írásáig (És még 14 
téma). 


2555/2565 - Windows alkalmazások 
fejlesztése C$.NET/VB.NET-tel 

Hogyan írjunk klasszikus Windows alkal- 
mazást .NET Framework alapon? Ez már 
nem VB6, itt másképp kell gondolkodni, de 
sokkal hatékonyabb alkalmazásokat fejleszt- 
hetünk. 


2389 - Az ADO.NET programozása 
Adatbázisalapú — .NET-es alkalmazások 
fejlesztése. ADO.NET A-tól Z-ig, SOL Server 
2000 alapokon. 


2524 - XML akezárági újjáátaátáss fejlesztése 
ASP.NET segítségéve 

Minden, amit a webszervizekről tudni kell. 
Nem je le a (WebMethod] attribú- 
tumnál, hanem titkosítással, hitelesítéssel és 
mindenféle nagyon praktikus és hasznos 
dologgal felvértezett valódi webszervizeket 
írunk a tanfolyamon. 


A tanfolyamok helyszíne 


A NetAcademia Kft. világörökségi KÖMESZEÉKEN várja hallgatóit Budapesten az Andrássy út 
62-ben! 


Megközelíthető az alábbi tömegközlekedési 
eszközökkel: 


e a Milleniumi kisföldalattival (Vörösmarty utca) 


e 4-es és 6-os villamossal (Oktogon) 


e vonattal (a Nyugati pályaudvartól 10 perc séta) 


Ingyenes parkolási lehetőség a Felvonulási téren. 


További elérhetőségeink: 


Telefon:  1/472-1214 
Fax: 1/472-1215 
E-mail: — info(Dnetacademia.net 


Weblap:  http://vww.netacademia.net 





